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Abstract: A new formal model is presented, for studying concurrency and resiliency properties for nested 
transactions. The model is used to state and prove correctness of a well-known locking algorithm. 

I. Introduction 

ITiis paper develops the foundation for a general theory of nested transactions. We present a simple formal 
model for studying concurrency and resiliency in a nested environment. This model has distinct advantages 
over the many alternatives, the greatest of which is the unification of a subject replete with formalisms, 
correctness conditions and proof techniques. 'JTie authors arc presently engaged in an ambitious project to 
recast the substantial amount of work in nested transactions within this single intuitive framework. 'ITiesc 
pages contain the preliminary results of that project - a description of the model, and its use in stating and 
proving correctness conditions for two variations of a well-known algorithm. 

The model is based on I/O automata, a simple formalization of communicating automata. It is not complex 
- it is easily presented in a few pages, and easy to understand, given a minimal background in automata 
theory. Kach nested transaction and data object is modelled by a separate I/O automaton. These automata, 
the system primitives, issue requests to and receive replies from some scheduler, which is simply another I/O 
automaton. Simple syntactic constraints on the interactions of these automata ensure, for example, that no 
transaction requests the creation of the same child more than once. One scheduler, in this case the "serial 
scheduler", interacts with the transactions and objects in a particularly constrained way. The "serial 
schedules" of the primitives and the serial scheduler arc the basis of our correctness conditions. Specifically, 
alternative schedulers arc required to ensure that nested transaction automata individually have local 
schedules which they could have in a serial schedule. In essence, each scheduler must "fool" the transactions 
into believing that the system is executing in conjunction with the serial scheduler. 

In the past ten years, an important and substantial body of work has appeared on the design and analysis of 
algorithms for implementing concurrency control and resiliency in database transaction systems 
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|I\G1 T.RI .S.NG.KS.Gr.l .aS, etc.]. Among this has been a number of results dealing with nested transactions 
|R,Mo.l.iS,I.IIJI.SW,AM,UIJGLS,HIKj, etc.]. The present work docs not replace these other contributions, 
but augments them by providing a unifying and mathematically tractable framework for posing and exploring 
a variety of questions. This previous work uses behavioral specifications of nested transactions, focusing on 
what nested transactions do, rather than what they arc. By answering the question "What is a nested 
transaction?", I/O automata provide a powerful tool for understanding and reasoning about them. 

Some unification is vitally important to further development in this field. The plethora and complexity of 
existing formalizations is a challenge to the most seasoned researcher. More critically, it belies the argument 
that nested transactions provide a clean and intuitive tool for organizing distributed databases and more 
general distributed applications. It is particularly important to provide an intuitive and precise description of 
nested transactions themselves, as in typical systems, these arc the components which the application 
programmer must implement! 

'ITic remainder of this paper is organized as follows. The I/O automaton model is described in Section 2. 
The rest of the paper contains an extended example, which establishes correctness properties for two related 
lock-based concurrent schedulers. 

Section 3 contains simple definitions for naming nested transactions and objects, and for specifying the 
operations (interactions) of these components. Simple syntactic restrictions on the orders of these operations 
arc presented, and then a particular system of I/O automata is presented, describing the interactions of nested 
transactions and objects with a serial scheduler. The interface between the serial scheduler and the 
transactions provides a basis for the specification of correctness conditions for alternative schedulers. These 
schedulers would presumably be more efficient than the serial scheduler. The strongest correctness condition, 
"serial correctness," requires that all non-access transactions sec serial behavior at their interface with the 
system. The second condition, "correctness for T ," only requires that this serial interface be maintained at 
the interface of the system and the external world. ITicsc interfaces also provide simple descriptions of the 
environment in which nested transactions can be assumed to execute. A particular contribution is the clear 
and concise semantics of ABORT operations which arises naturally from this formalization. The section 
closes with a collection of lemmas describing useful properties of serial systems. 

Next a lock -based concurrent system is presented. Section 4 contains a description of a special type of 
object, called a "resilient object", which is used in the concurrent system. Section 5 describes the remainder 
of the concurrent system, the "concurrent scheduler." This concurrent scheduler includes "lock manager" 
modules for all the objects; lock managers coordinate concurrent accesses. 



Section 6 defines a system which is closely related to the concurrent system, the "weak concurrent system." 
This system preserves serial correctness for those transactions whose ancestors do not abort (i.e.. those that arc 
not "orphans"). Since the root of the transaction tree, T () , has no ancestor, weak concurrent systems arc 
correct for 1" Section 7 contains complete proofs of correctness of the concurrent and weak concurrent 
sytcms; concurrent systems arc serially correct, and weak concurrent systems arc correct for T Q . The stronger 
condition is obtained for concurrent systems as a corollary to a result about weak concurrent systems. 

It is interesting that the concurrent system algorithms arc described in complete detail (essentially, in 
"pseudocode"), yet significant formal claims about their behavior can be suited clearly and easily. Although 
the full presentation involves a large number of lemmas, the ideas described by the lemmas arc quite simple 
and intuitive. We think it is remarkable that these interesting properties of concurrent systems can be proved 
with complete rigor, in full detail, in so short a development. Despite the detailed level of presentation, the 
underlying model is general enough that the results apply to a wide range of implementations. 

The style of the correctness proof is also noteworthy. It is a constructive proof, in that for each step of the 
weak concurrent system and each non-orphan transaction, an execution of the serial system is explicitly 
constructed. The transaction's local "view" in the constructed execution is identical to that in the original 
weak concurrent execution, establishing the correctness of the weak concurrent system. One may think of the 
weak concurrent system as maintaining consistent, parallel "world views" within which concurrent siblings 
execute. As siblings return to their parent, these parallel worlds arc "merged" to form a single consistent 
view. The locking policy prevents collisions between different views at the shared data. This intuition is 
strongly supported and clarified by the correctness proof, which constructs the parallel views as different 
serial schedules consistent with each sibling's local history. Lemmas illustrate how these serial schedules can 
be merged as siblings return or abort to their parent 

Section 8 contains a discussion of the relationship of this work to previous results, and Section 9 contains an 
indication of the work that lies ahead. 

2. Basic Model 

In this section, we present the basic I/O automaton model, which is used to describe all components of our 
systems. This model consists of rather standard, possibly infinite-state, nondctcrministic automata that have 
operation names associated with their state transitions. Communication among automata is described by 
identifying their operations. This model is very similar to models used by Milncr, Hoarc [Mi,Ho] and others. 
There arc a few differences: first, we find it important to classify operations of any automaton or system of 
automata as cither "input" or "output" operations, of that automaton or system, and we treat these two cases 
differently. Also, we allow identification of arbitrary numbers of operations from different automata, rather 



(.han just pairwisc identification as considered in [Mi]. 

This paper is not intended to develop the basic model. For the general theory of I/O automata, including a 
unified treatment of finite and infinite behavior, we refer the reader to [I.T]. In the present treatment of 
concurrent transaction systems, we only prove properties of finite behavior, so we only require a simple 
special case of the general model. 

2.1. I/O Automata 

All components in our systems, transactions, objects and schedulers, will be modelled by I/O automata. An 
I/O automaton A has components statcs(A), start(A), oul(A). in(A). and stepsfA). Here, statcsfJ.) is a set of 
states, of which a subset start(A) is designated as the set of start states. The next two components arc disjoint 
sets: out(A) is the set of output operations, and in(A) is the set of input operations. The union of these two 
sets is the set of operations of the automaton. Finally, stepsfA) is the transition relation of A, which is a set of 
triples of the form (s',w,s), where s' and s arc states, and ir is an operation. This triple means that in state s\ 
the automaton can atomically do operation it and change to suite s. An clement of the transition relation is 
called a step of X 

The output operations arc intended to model the actions that arc triggered by the automaton itself, while 
the input operations model the actions that arc triggered by the environment of the automaton. Our 
partitioning of operations into input and output indicates that each operation is only triggered in one place. 
We require the following condition. 

Input Condition: For each input operation it and each state s', there exist a state s and a step (s\w,s). 

This condition says that an I/O automaton must be prepared to receive any input operation at any time, 
'["his condition makes intuitive sense if we think of the input operations as being triggered externally. (In this 
paper, this condition serves mainly as a technical convenience, but in [LT], where infinite behavior is 
considered, it is critical.) 

An execution of A is an alternating sequence s ,7r,, s v v y ... of states and operations of A; the sequence may 
be infinite, but if it is finite, it ends with a state. Furthermore, s Q is in starts), and each triple (s'.w.s) which 
occurs as a consecutive subsequence is a step of A. From any execution, we can extract the schedule, which is 
the subsequence of the execution consisting of operations only. Because transitions to different states may 
have the same operation, different executions may have the same schedule. 

Umma 1: If a is a schedule of I/O automaton A, then every prefix of a is a schedule of X 



If S is any set of schedules (or property of schedules), then J. is said to preserve S provided that the 
following holds. If a = air is any schedule of J., where it is an output operation, and a* is in S. then a is in 
S. That is, the automaton is not the first to violate the property described by S. 

2.2. Composition of Automata 

We describe systems as consisting of interacting components, each of which is an I/O automaton. It is 
convenient and natural to view systems as I/O automata, also. Thus, wc define a composition operation for 
I/O automata, to yield a new I/O automaton. 

A set of I/O automata may be composed to create a system 5, if all of the output operations arc disjoint. 
(Thus, every output operation in % will be triggered by exactly one component.) The system J is itself an I/O 
automaton. A state of the composed automaton is a tuple of suites, one for each component, and the start 
states arc tuples consisting of start states of the components. The set of operations of J, ops(f), is exactly the 
union of the sets of operations of the component automata. 'ITic set of output operations of if, oul(f), is 
likewise the union of the sets of output operations of the component automata. Kinally, the set of input 
operations of 5, in(f), is ops(J) - out(f), the set of operations of $ that arc not output operations of t. ITie 
output operations of a system are intended to be exactly those that arc triggered by components of the system, 
while the input operations of a system arc those that arc triggered by the system's environment 

The triple (s'.w.s) is in the transition relation of $ if and only if for each component automaton A, one of the 
following two conditions holds. Either m is an operation of X and the projection of the step onto J. is a step 
of X or else w is not an operation of Ji, and the states corresponding to JL in the two tuples s* and s arc 
identical. Thus, each operation of the composed automaton is an operation of a subset of the component 
automata. During an operation it of £ each of the components which has operation ti carries out the 
operation, while the remainder stay in the same state. Again, the operation m is an output operation of the 
composition if it is the output operation of a component - otherwise, w is an input operation of the 

composition. 

tamma 2: The composition of I/O automata is an I/O automaton. 

The next lemma allows us to compose automata in any order. 

Lemma 3: Up to isomorphism, composition of I/O automata is associative and commutative. 



Note that our model has chosen a particular convention for identifying operations of different components in a system: we simply 
identify those with the same name. Ihis convention is simple, and sufficient for what wc do in this paper. I lowever, when this work is 
extended to more complicated systems, it may be expedient to generalize the convention for identifying operations, to permit reuse of the 
same operation name internally to different components. Ihis will require introducing a renaming operator for operations, or else 
defining composition with respect to a designated equivalence relation on operations. We leave this for later work. 



An execution of a system is defined to be an execution of the automaton composed of the individual 
automata of the system. If a is a schedule of a system with component A, then we denote by a\A the 
subsequence of a containing all the operations of A. Clearly, a\A is a schedule of J.. 

Icniina 4: l.ct a be a schedule of a system X and let a = a'n, where m is an output operation 
of component A. If a\ A is a schedule ol 'A. then a is a schedule of J". 

Proof: Since a\A is a schedule of A, there is an execution ft of A with schedule a\A. l.ct/T be 
the execution of A consisting of all but the last step of ft. Similarly, since a' is a schedule of !f, 
mere is an execution y of !f with schedule a'. It is possible that A has an execution in y which is 
different from ft', since different executions may have the same schedule. Hut it is easy to show, 
by induction on the length of 7, that there is another execution y' of 'S in which component A has 
execution /?', and which is otherwise identical to y. The schedule of y' is a\ Since it is not an 
output operation of any other component, ir is defined from the state reached at the end of y\ so 
that a = av is a schedule of S. I 

3. Serial Systems 

In this paper, we define three kinds of systems: "serial systems" and two types of "concurrent systems". 
Serial systems describe serial execution of transactions. Serial systems arc defined for the purpose of 
providing a correctness condition for other systems: that the schedules of the other systems should "look 
like" schedules of the serial system to the transactions. As with serial schedules of single-level transaction 
systems, our serial schedules arc too inefficient to use in practice. Thus, we define systems which allow 
concurrency, and which permit the abort of transactions after they have performed some work. Wc then 
prove that the schedules permitted by concurrent systems arc correct. 

In this section, wc define "serial systems". Serial systems consist of "transactions" and "basic objects" 
communicating with a "serial scheduler". Transactions and basic objects describe user programs and data, 
respectively. The serial scheduler controls communication between the other components, and thereby 
defines the allowable orders in which the transactions may take steps. All three types of system components 
arc modelled as I/O automata. 

Wc begin by defining a structure which describes the nesting of transactions. Namely, a system type is a 
four-tuple (^parcnt,0,V), where ^ the set of transaction names, is organized into a tree by the mapping 
parcnt:?T— ♦ f! with T Q as the root. In referring to this tree, wc use traditional terminology, such as child, leaf, 
least common ancestor (lea), ancestor and descendant. (A transaction is its own ancestor and descendant.) 
'Ihc leaves of this tree are called accesses. The set denotes the set of objects; formally, is a partition of the 
set of accesses, where each clement of the partition contains the accesses to a particular object The set V is a 
set of values, to be used as return values of transactions. 

The tree structure can be thought of as a predefined naming scheme for all possible transactions that might 



ever be invoked. In any particular execution, however, only some of these transactions will actually take 
steps. We imagine that the tree structure is known in advance by all components of a system. The tree will, in 
general, be an infinite structure. 

The classical transactions of concurrency control theory (without nesting) appear in our model as the 
children of a "mythical" transaction, '1 , the root of the transaction tree. (In work on nested transactions, such 
as ARGUS |l.iS,l HJI.SW], the children of l' arc often called "top-level" transactions.) It is very convenient 
to introduce the new root transaction to model the environment in which the rest of the transaction system 
runs. Transaction T fl has operations that describe the invocation and return of the classical transactions. It is 
natural to reason about T Q in much the same way as about all of the other transactions, although it is 
distinguished from the other transactions by having no parent transaction. Since committing and aborting arc 
operations which take place at the parent of each transaction (sec below), 'I' can neither commit nor abort. 
Thus, a commit or abort of a top-level transaction to T Q is an irreversible step. 

The internal nodes of the tree model transactions whose function is to create and manage subtransactions, 
but not to access data directly. The only transactions which actually access data arc the leaves of the 
transaction tree, and thus they arc distinguished as "accesses". The partition simply identifies those 
transactions which access the same object. 

A serial system of a given system type is the composition of a set of I/O automata. This set contains a 
transaction for each internal (i.e. non-leaf, non-access) node of the transaction tree, a basic object for each 
clement of and a serial scheduler. These automata arc described below. (If X is a basic object associated 
with an clement 3> of the partition 0, and T is an access in 95, wc write T € accessesfX) and say that "T is an 
access to X".) 

3.1. Transactions 

This paper differs from earlier work such as [Ly,Go,Wcl] in that wc model the transactions explicitly, as 
I/O automata. In modelling transactions, wc consider it very important not to constrain them unnecessarily; 
thus, wc do not want to require that they be expressible as programs in any particular high-level programming 
language. Modelling the transactions as I/O automata allows us to state exactly the properties that are 
needed, without introducing unnecessary restrictions or complicated semantics. 

A non-access transaction T is modelled as an I/O automaton, with the following operations. 

Input operations: 
CRKATK(T) 

COMMlT(T',v), forT € childrcn(T) and v € V 
AIJORT(T), for T € childrcn(T) 



Ouiput operations: 

RI'.QUI ; .SI -CRKA I'hX'l"). fori'' € childrcn(T) 
KI'QUHS'I -COMMH(l'.v), forv € V 

The CRI-Ali: input operation "wakes up" the transaction. The RKQUKST-CRKATK output operation is 
a request by T to create a particular child transaction. 2 The COMMIT input operation reports to T the 
successful completion of one of its children, and returns a value recording the results of that child's execution. 
The ABORT input operation reports to T the unsuccessful completion of one of its children, without 
returning any other information. We call COMMIT('r,v), for any v, and AUOR T(T) return operations for 
transaction I". The RKQUKST-COMMIT operation is an announcement by T that it has finished its work, 
and includes a value recording the results of that work. 

It is convenient to use two separate operations, RKQUKST-CRKATK and CRKATK, to describe what 
takes place when a subtransaction is activated. The RKQUKST-CRKA TH is an operation of the 
transaction's parent, while the actual CRKATK takes place at the subtransaction itself. In actual systems such 
as ARGUS, this separation docs occur, and the distinction will be important in our results and praofs. Similar 
remarks hold for the RKQUKS'I -COMMIT and COMMIT operations. 3 We leave the executions of 
particular transaction automata largely unspecified; the choice of which children to create, and what value to 
return, will depend on the particular implementation. Kor the purposes of the schedulers studied here, the 
transactions (and in large part, the objects) arc "black boxes." Nevertheless, it is convenient to assume that 
schedules of transaction automata obey certain syntactic constraints. 'Thus, transaction automata arc required 
to preserve well-formedness, as defined below. 

We recursively define well-formedness for sequences of operations of transaction T. Namely, the empty 
schedule is well-formed. Also, if a = am is a sequence of operations of T, where w is a single operation, 
then a is well-formed provided that a is well-formed, and the following hold. 

• IfwisCRKATHfO.thcn 

(i) there is no CRKATK(T) in a. 

• If it is COMMlT(T\v) or AHORTfT) for a child T of T, then 



2 Notc that there Ls no provision for T to pass information to its child in this request. In a programming language. T might be 
permitted to pass parameter values to a subtransaction. Although this may be a convenient descriptive aid. it Ls not necessary to include 
in it the underlying formal model. Instead, we consider transactions that have different input parameters to be different transactions. 

3 Notc that we do not include a Rl-QUI-S'l - AHORT operation for a transaction: we do not model the situation in which a transaction 
decides that its own existence is a mistake. Rather, we assign decisions to abort transactions to another component of the system, the 
scheduler. In practice, the scheduler must have some power to decide to abort transactions, as when it detects deadlocks or failures. In 
ARGUS, transactions arc permitted to request to abort: we regard this request simply as a "hint" to the scheduler, to restrict its allowable 
executions in a particular way. Ih is operation could be made explicit, constraining the scheduler to abort the requesting transaction, 
without substantively changing the model or results. 



(i) RLQULST-CRLATIH') appears in a and 
(ii) there is no return operation for T' in a\ 

• U'tt is RHQULST-CRHATI-X T'j for a child T of T. then 
(i) there is no RLQULS T-CRHA IITH in a 

(ii) there is no RLQUKST-COMMIHT) in a' and 
(iii)CRLA TL( I) appears in a'. 

• If w isa RI-QUI-ST- COMMIT fori', then 

(i) there is no RLQULST-COMMIT fori' in a and 
(ii)CRLA TfX'l) appears in a. 

These restrictions arc very basic; they simply say that a transaction docs not get created more than once, 
docs not receive repeated notification of the fates of its children, docs not receive conflicting information 
about the fates of its children, and docs not receive information about the fate of any child whose creation it 
has not requested; also, a transaction docs not perform any output operations before it has been created or 
after it has requested to commit, and docs not request the creation of the same child more than once. Kxccpt 
for these minimal conditions, there arc no restrictions on allowable transaction behavior. For example, the 
model allows a transaction to request to commit without discovering the fate of all subtransactions whose 
creation it has requested. Also, a transaction can request creation of new subtransactions at any time, without 
regard to its state of knowledge about subtransactions whose creation it has previously requested. Particular 
programming languages may choose to impose additional restrictions on transaction behavior. (An example is 
ARGUS, which suspends activity in transactions until subtransactions complete.) However, our results do not 
require such restrictions. 

The following easy lemma summarizes the properties of well-formed sequences of transaction operations. 
Lemma 5: Let a be a well-formed sequence of operations of transaction T. ITicn the following 
conditions hold. 

1. The first operation of a is a CREATE(T) operation, and there arc no other CREATE 
operations. 

2. If a REQUEST -COM MIT operation occurs in o, then there arc no later output 
operations in a. 

3. There is at most one REQUEST -CREATEO") operation for each child T of T, in a. 

4. Every return operation in a has a preceding REQUEST- CREATE operation in a for the 
same child transaction. 



3.2. Basic Objects 

Recall that I/O automata arc associated with non-access transactions only. Since access transactions model 
abstract operations on shared data objects, we associate a single I/O automaton with each object, rather than 
one for each access. The operations for each object arc just the CRKATK and RKQUKS'I -COMMI T 
operations for all the corresponding access transactions. Although we give these operations the same names as 
the operations of non-access transactions, it is helpful to think of the operations of access transactions in other 
terms also: a CRKATK corresponds to an invocation of an operation on the object, while a 
RKQUKST -COM MIT corresponds to a response by the object to an invocation. Actually, these CRKATK 
and RKQUKST -COM MIT operations generalize the usual invocations and responses in that our operations 
carry with them a designation of the position of the access in the transaction tree. We depart from the 
traditional notational distinction between creation of subtransactions and invocations on objects, since the 
common terminology for access and non-access transactions is of great benefit in unifying the statements and 
proofs of our results. Thus, a basic object X is modelled as an automaton, with the following operations. 

Input operations: 

CRKA TK(T), for T in acccsscs(X) 

Output operations: 

RKQUKS T-COMMI T(T.v), fori' in acccsscs(X) 

ITie CRKATK operation is an invocation of an access to the object, while the RKQUKST -COM MIT is a 
return of a value in response to such an invocation. 

As with transactions, while specific objects arc left largely unspecified, it is convenient to require that 
schedules of basic objects satisfy certain syntactic conditions. Thus, each basic object is required to preserve 
well-formedness, defined below. 

Let o be a sequence of operations of basic object X. Then an access T to X is said to be pending in a 
provided that there is a CRKATKf 0. but no RKQUKST- COM MIT for T, in a. We define well-formedness 
for sequences of operations of basic objects recursively. Namely, the empty schedule is well-formed. Also, if 
a = ait is a sequence of operations of basic object X, where it is a single operation, then a is well-formed 
provided that a is well-formed, and the following hold. 

• IfwisCRKATK<T).thcn 

(i) there is no CRKATK(T) in a, and 
(ii) there arc no pending accesses in a. 

• \fw is RKQU KST- COMMIT for T, then 

(i) there is no RKQUKST-COMMIT for T in er\ and 
(ii) CRKATK( T) appears in a. 
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These restrictions simply say that the same access docs not gel created more than once, nor docs a creation 
of a new access occur at a basic object before the previous access has completed (i.e. requested to commit); 
also, a basic object docs not respond more than once to any access, and only responds to accesses that have 
previously been created. 

The following easy lemma summarizes the properties of well-formed sequences of basic object operations. 

Lemma 6: let a be a well-formed sequence of operations of basic object X. Then a consists of 
alternating CRKATK and RKQUKST-COMMIT operations, starting with a CRKATK, and with 
each consecutive (CRKA TK,RKQUKST-COMMH ) pair having a common transaction. 

3.3. Serial Scheduler 

The third kind of component in a serial system is the serial scheduler. The serial scheduler is also modelled 
as an automaton. The transactions and basic objects have been specified to be any I/O automata whose 
operations and behavior satisfy simple syntactic restrictions. The serial scheduler, however, is a fully specified 
automaton, particular to each system type. It runs transactions according to a depth-first traversal of the 
transaction tree. The serial scheduler can choose nondctcrministically to abort any transaction after its parent 
has requested its creation, as long as the transaction has not actually been created. In the context of this 
scheduler, the "semantics" of an ABORTfT) operation arc that transaction T was never created, llie 
operations of the serial scheduler arc as follows. 

Input Operations: 

RKQUKST-CRKATK(T) 
RKQU KST- COMM IT( T,v) 

Output Operations: 

CRKATHCT) 

COMMIT(T.v) 

ABORT(T) 

The RKQUKST-CRKATK and RKQUKST-COMMIT inputs arc intended to be identified with the 
corresponding outputs of transaction and object automata, and correspondingly for the CRKATK, COMMIT 
and ABORT output operations. Kach state s of the serial scheduler consists of four sets: 
create - rcqucstcd(s), crcatcd(s), commit- rcqucstcd(s), and rcturncd(s). The set commit- rcqucstcd(s) is a 
set of (transaction, value) pairs. The others arc sets of transactions. there is exactly one initial state, in which 
the set create- requested is {T }, and the other sets are empty. 

The transition relation consists of exactly those triples (s'.w.s) satisfying the pre- and postconditions below, 
where m is the indicated operation. For brevity, we include in the postconditions only those conditions on the 
state s which may change with the operation. If a component of s is not mentioned in the postcondition, (such 
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as rcturncd(s) in the postcondition Cor RKQUEST-CREATKfT)), it is implicit that the set is the same in s' 
and s (that returncd(s') = rclumcd(s). in this example). Note that here, as elsewhere, we have tried to specify 
the component as nondctcrministically as possible, in order to achieve Line greatest possible generality for our 
results. 

• RKQUKST-CRKAThXT) 
Postcondition: 

create— rcqucstcd(s) = create- rcqucsted(s') U {'I'} 

• RKQUEST-COMMIT(T,v) 
Postcondition: 

commit- rcqucstcd(s) = commit- rcquestcd(s') U {(T,v)} 

• CREATE(T) 
Precondition: 

I' € create- rcqucstcd(s') - created^*) 

siblings( I) D crcatcd(s') C rcturncd(s') 

Postcondition: 

crcatcd(s) = crcatcd(s') U {T} 

• COMMIT(T,v) 
Precondition: 

(T,v) € commit- rcquestcd(s') 

T £ rcturncd(s') 

childrcn(T) n create — requcstcd(s') C rcturned(s') 

Postcondition: 

rcturncd(s) = rcturncd(s') U {T} 

• ABORT(T) 
Precondition: 

T € create- requested^') - crcatcd(s') 

siblingsCl) n crcatcd(s') C rcturncd(s') 

Postcondition: 

crcatcd(s) = crcatcd(s') U {T} 

rcturncd(s) = rcturned(s') U {T} 

The input operations, REQUEST- CREATE and REQUEST -COM MIT, simply result in the request 
being recorded. A CREATE operation can only occur if a corresponding REQUEST— CREATE has 
occurred and the CREATE has not already occurred. 'ITic second prccondiition on the CREATE operation 
says that the serial scheduler docs not create a transaction until all its previously created sibling transactions 
have returned. That is, siblings arc run sequentially. 'ITic precondition on the COMMIT operation says that 
the scheduler docs not allow a transaction to commit to its parent until its children have returned. The 
precondition on the ABORT operation says that the scheduler docs not abort a transaction while there is 
activity going on on behalf of any of its siblings. That is, aborted transactions are run sequentially with 
respect to their siblings. The next lemma relates a schedule of the serial scheduler to the state which results 
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from applying that schedule. 

Lemma 7: Let a be a schedule of the serial scheduler, and let s be a state which can result from 
applying a to the initial state. Then the following conditions arc true. 

l.T is in create- rcqucstcd(s) exactly if T = T fl or a contains a RHQUKST-CRKAITX'T) 
operation. 

2. T is in crcatcd(s) exactly if a contains cither a CRKA ITX'T) or AUORT(T) operation. 

3. (T,v) is in commit- rcqucstcd(s) exactly if a contains a RHQUKST-COMMIT(T,v) 
operation. 

4. T is in rcturncd(s) exactly if a contains a return operation for T. 

3.4. Serial Systems and Serial Schedules 

In this subsection, we define serial systems precisely and provide some useful terminology for talking about 
them. 

The composition of transactions with basic objects and the serial scheduler for a given system type is called 
a serial system. Define the serial operations to be those operations which occur in the serial system: 
RFQUKST-CRKATKS, RKQUKST- COMMITS, CREATES, COMMITS and ABORTS. The schedules 
of a serial system are called serial schedules. The non-access transactions and basic objects arc called the 
system primitives. (Recall that each basic object is an automaton corresponding to a set of access transactions. 
Thus, individual access transactions arc not considered to be primitives.) 

Recall that the operations of the basic objects have the same syntax as transaction operations. It is 
convenient to refer to CREATE(T) and RKQUKST-COMMlTfT), when T is an access to basic object X, 
both as operations of transaction T and of object X. To avoid confusion, it is important to remember that 
there is no transaction automaton associated with any access operation. 

For any serial operation w, wc define transaction(v) to be the transaction at which the operation occurs. 
(For CREATE(T) operations and REQUEST -COM MIT operations for T, the transaction is T, while for 
REQUKST-CREATE(T) operations, and COMMIT and ABORT operations for T, the transaction is 
parcnt(T).) For a sequence a of serial operations, transaction(o) is the set of transactions of the operations in 



Two sequences of serial operations, a and a, are said to be equivalent provided that they consist of the 
same operations, and a|P = a'|P for each primitive P. Obviously, this yields an equivalence relation on 
sequences of serial operations. 
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Wc let rt|T denote the subsequence of a consisting of operations whose transaction is T, even if T is an 
access. (This is an extension of the previous definition of a\ T. as accesses arc not component automata of the 
serial system.) 

Let a be a sequence of serial operations. Wc say that a transaction T is live in a provided that a 
CRI-ATIX I ), but no COMM IT( T,v) or AIIORT(T), occurs in a. Wc say that transaction T is visible to T in a 
provided tliat for each ancestor I"" of I" which is a proper descendant of lca( 1,1 '), some COMMN'(T",v) 
occurs in a. (In particular, any ancestor of T is visible to T in a.) For sequence a and transaction T, let 
visibli{a.T) be the subsequence of a consisting of operations whose transactions arc visible to T in a. (These 
include access transactions T.) Wc say that transaction T sees everything in a provided that visiblc(a,T) = a. 

This is the same definition of visibility as appears, in a different model, in [l.y]. Visibility captures an 
intuitive notion suggested by the name: the transactions visible to a transaction T in a arc those whose effects 
T is permitted to "sec" in a. If transaction T is visible to transaction T in a, it means that descendants of T 
may have passed to T information about T\ obtained by accessing objects that were previously accessed by 
descendants of T. 

If a is a sequence of operations, not necessarily all serial, then define scrial(o) to be the subsequence of a 
consisting of the serial operations. Wc say that T is live in a provided that it is live in scrial(a). Wc say that T* 
is visible to T in a if T is visible to T in scrial(a). and define visiblc(a,T) to be visiblc(scrial(a),T). Also, T 
sees everything in a provided that T sees everything in scrial(a). Similarly, define transaction(a) = 
transaction(scrial(a)). 

A sequence a of serial operations is said to be well-fonnedifils projection at every primitive is well-formed. 

3.5. Correctness Condition 

Wc use serial schedules as the basis of our correctness definitions. Namely, wc say that a sequence of 
operations is serially correct for a primitive P provided that its projection on P is identical to the projection on 
P of some serial schedule. Wc say that any sequence of operations is serially correct if it is serially correct for 
every non-access transaction. That is, a "looks like" a serial schedule to every non-access transaction. 

In the remainder of this paper, wc define two systems: concurrent systems and weak concurrent systems. 
Wc show that schedules of concurrent systems arc serially correct, and that schedules of weak concurrent 
systems arc serially correct for T«. 

Thus, wc use the serial scheduler as a way of describing desirable behavior, just as serial schedules describe 
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desirable behavior in more classical concurrency control settings (those without nesting). Then serial 
correctness plays the role in our theory that scriali/ability plays in classical settings. 

Motivation for our use of serial schedules to define correctness derives from the simple behavior of the 
serial scheduler, which determines the sequence of interactions between the primitives. Kach transaction T is 
created only after parcnt( T) requests it, no siblings of 1' arc created until 'I' has returned, T is not committed 
until each of its requested children has itself returned, and T is not aborted until each of its created siblings 
has returned. The result is a depth-first traversal of the transaction tree, with requests flowing down and 
responses flowing up. We believe this depth-first traversal to be a natural notion of correctness which 
corresponds precisely to the intuition of how nested transaction systems ought to behave. Furthermore, it is a 
natural generalization of scriali/ability, the correctness condition generally chosen for classical transaction 
systems. 

Serial correctness is a condition which guarantees to implcmcntors of transactions that their code will 
encounter only situations which can arise in serial executions. Correctness for T fl is a natural alternative, 
which guarantees only that the external world will encounter only situations which can arise in serial 
executions. This condition permits less constrained implementations, in that schedulers in such systems need 
not insure that orphans sec consistent data. On the other hand, in such systems the authors of transactions 
must insure that their programs behave well even if they sec inconsistencies. (For example, orphans that see 
inconsistent data should not consume too many system resources, garble data beyond repair, dispense drugs 
or initiate military hostilities.) We hope this work will provide a tool for exploring the inherent costs of 
different correctness conditions such as these. 

Note that our correctness conditions arc defined at the transaction interface only, and do not constrain the 
object interface. We believe that this makes the conditions more meaningful to users, and more likely to 
suffice for a large variety of algorithms, which may use a variety of back-out, locking or version schemes to 
implement objects. Previous work has focusscd on correctness conditions at the object interface [KGLT, etc.]. 
While we believe that object interface conditions arc important, their proper role in the theory is not to serve 
as the basic correctness condition. Rather, they arc useful as intermediate conditions for proving correctness 
of particular implementations: such conditions can be shown to be sufficient, in combination with an 
appropriate scheduler, to ensure our correctness condition at the transaction interface. This observation is an 
important unifying contribution of our work. Our current research is focussing on demonstrating the 
usefulness of this approach, for a variety of object interface correctness conditions. 

The serial correctness condition says that a schedule a must look like a serial schedule to each non-access 
transaction; this allows for the possibility that a might look like different serial schedules to different non- 
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access transactions. This condition may at first seem to be too weak. It may seem that wc should require that 
all transactions sec a projection of the same serial schedule. Hut this stronger condition is not satisfied by most 
of the known concurrency control algorithms. It is true that stronger conditions than ours can sometimes be 
proved, but such conditions arc more complicated to slate, and it is not yet clear which such conditions arc 
most interesting. 

The serial correctness condition is really not as weak as it may seem at first because T Q , the root transaction, 
is included among the transactions to which a must appear serial. As discussed above, transaction T Q can be 
thought of as modelling the environment in which the rest of die transaction system runs. Its 
RKQUF.S T— CRF.A IF operations correspond to the invocation of top-level transactions, while its COMMIT 
and A1JORT operations correspond to return values and external effects of those transactions. Since ar's 
projection on T. must be serial, the environment of the transaction system will sec only results that could arise 
in a serial execution. Indeed, this is the justification of the correctness condition for the weak concurrent 
system, whose schedules arc shown to be correct for I ' but not necessarily for any other transaction. 

It is possible to use a different serial scheduler as a basis for correctness conditions. For example, the 
scheduler might delay creating one sibling until another requests to return, rather than until it actually returns 
to the parent [Wc2]. Such a scheduler would provide less information to the parent about the actual order in 
which its children arc executed, and conscquendy provide more freedom for concurrent schedulers to 
schedule various events. Timcstamp-bascd systems such as [R] may support this weaker correctness 
condition, radicr than the one described above, but tliis remains to be studied. 

Our approach is really a general technique for studying operating system algorithms. A simple, intuitive 
and inefficient algorithm (automaton) is used to specify a "contract" between the users and implcmcntor of 
an operating system. ITic user is guaranteed that applications (transactions, in our work) which arc correct 
when run with the simple algorithm will also be correct when run with the actual operating system, which 
presumably will be more efficient On the other hand, the implcmcntor also has a formal and intuitive 
specification of the user interface. 

3.6. Properties of Serial Systems 

In this subsection, we prove a number of lemmas about the behavior of serial systems. 'ITicy arc collected 
here for reference later in this paper and in future work. Most of the lemmas describe properties that are 
quite easy to understand and believe, and the corresponding proofs arc very straightforward. In the last 
paragraph of this subsection, there arc some specialized lemmas that arc somewhat more difficult These arc 
used in the proof of the main theorem in Section 7. 
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3.6.1. Fundamental Properties of Visibility 

The first lew lemmas give fundamental properties of visibility in sequences of serial operations. In this 
paragraph, we do not even require that the sequences be schedules of serial systems, but only mat they be 
sequences of serial operations. The proofs of these lemmas arc straightforward from the definitions. 
Lemma 8: I .ct a be a sequence of serial operations, and T, I" and T" transactions. 

1. Iff* is a descendant of T, then T is visible to T in or. 

2. T is visible to T in or if and only if 'I" is visible to lca(T,T') in a. 

3. IfT" is visible to I" in or and I" is visible to T in or, then T" is visible to T in or. 

4. If I" is a descendant of T and T" is visible to T in or, then T" is visible to T in a. 

5. If I" is a descendant of T and "I" is visible to T" in or, then T is visible to T" in a. 

6. IfT is a proper descendant of T, T' is visible to T in or, but T" is not visible to T in a, then 
T" is a descendant of the child of T which is an ancestor of T. 

Lemma 9: I .ct or and fi be sequences of serial operations, with fi a subsequence of a. 

1. If transaction T is visible to transaction T in fi, then it is visible to transaction T in a. 

2. If operation v is in visiblc(/3, T), then it is in visiblc(a,T). 

l/cmma 10: Let a, a\ fi and fi' be sequences of serial operations, and let T and T be 
transactions. 

1. If a is equivalent to a\ and T is visible to T in a, then T is visible to T in a. 

2. If a is equivalent to a\ then visib1c(a.T) is equivalent to visiblc(a\T). 

3. If fi is equivalent to fi\ then a- fi = a - fi\ 

4. If a is equivalent to or', and fi is equivalent to /T, then a - fi is equivalent to a - fi'. 

5. If fi = visiblc(a,T), then T sees everything in fi. 

6. If fi is equivalent to visiblc(a,T), then T sees everything in fi. 

1. Ufi = visiblc(a,T) and T is visible to T in a, then visib!c(y3,T) = visiblc(a,T). 

8. ]ffi is equivalent to visiblc(or, T), fi' is equivalent to visiblc(a.T), and T is visible to T in a, 
then fi' is equivalent to visiblc(/?,T). 

lamina 11: Let a be a sequence of serial operations, and let T and T be transactions. Then 
visiblc(a, T)|T is equal to a\T if T is visible to T in a, and is equal to the empty string otherwise. 

Lemma 12: I .ct air be a sequence of serial operations, where it is a single operation. Let T be a 
transaction and assume that transaction^) is visible to T in aw. Assume that it is not a COMMIT 
operation. Then visiblc(aw, T) = visiblc(or,T)w. 
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3.6.2. Operations in Serial Schedules 

The lemmas in this paragraph describe the kinds and orders of operations that can occur in well-formed 

serial schedules. In the next paragraph, we show thai all serial schedules arc well-formed, so that all these 

properties actually follow just from the fact that the schedules arc serial. 

Lemma 13: I .ct a be a well-formed serial schedule, and let T * '\\ be a transaction. 

1. If a contains any operation with transaction T, then a contains a 
RLQUKST-CRKATIXT). 

2. If a contains a COMMIT for T, then a contains a REQUEST -COM MIT for T, a 
CREA ITX'I) and a REQUEST- CREAThXT). 

3. If a contains an ABORT(T), then a contains a REQUES T-CREA TE< T). 

Proof: Straightforward from well-formedness and the scheduler preconditions. I 

Lemma 14: Let a be a well-formed serial schedule, and T a transaction. Assume that some 
descendant of T is in transaction(er). Then the following hold. 

l.CREATE(T) occurs inc. 

2. If T * T . then REQUEST- CREATEfT) occurs in a. 

Proof: 1. By induction on the length of a. I"hc basis is easy. Let a — a it, where w is a single 
operation, and assume that the result holds for a. Let I" = transaction^ ), and let T be any 
ancestor of I". We must show that CREAThX T) occurs in a. 

Because a is well-formed, CRHATLX I ') occurs in a. If T = T, we arc done. Otherwise, 
Lemma 13 implies that RKQUBS T-CRKATLX T) occurs in a. This occurs at parcnt(T), which is 
a descendant off. The inductive hypothesis then implies that a contains a CRHATK(T). 

2. By part 1. and Iximma 13. I 

Lemma 15: Let a be a serial schedule, and let T be a transaction. Then a cannot contain both a 
CRKATKO") and an AIK)RT(T) operation. 
Proof: Ity the scheduler preconditions. I 

Lemma 16: Let a be a well-formed serial schedule, and let T be a transaction. If AI)ORT(T) 
occurs in a, then a contains no operations whose transactions arc descendants of T. 

Proof: Assume the contrary. Then Lemma 14 implies that a CRKATE(T) operation occurs in a. 
Hut Ixmma 15 yields a contradiction. I 

Lemma 17: Let a be a well-formed serial schedule, and let T * T Q be a transaction. 

1. If a contains a RKQUEST-CRKATFXT), but docs not contain a return operation for T, 
then parcnt(T) is live in a. 

2. If T is live in a, then parcnt(T) is live in a. 

3. If a contains a REQUEST- CRKATK(T) but docs not contain a CREATE(T) or an 
ABORT(T). then parcnt(T) is live in o. 



Proof: 

1. Well-formedness implies that the RKQUKST-CRKATK(T) is preceded in a by a 
CRKA'ITXparcnt(T)). Suppose that parent! T) is not live in a. Then a return operation for 
parcntCI") occurs in a. liy lemma 15, ABOK T(parcnt( I )) cannot appear in a. Thus, a 
COMMIT operation for parcnt(T) must appear in a. This COMMIT operation for 
parcnl(T) must be preceded by a RKQUKST-COMMIT for parcnt(T), by the scheduler 
preconditions. By well-formedness, the RKQUKST-COMMIT for parcntCI) must follow 
the RKQUKST-CKKATIX T) operation, so that the COMMIT for parcnt(T) follows the 
RKQUKST-CRKATTX T) operation. Then by ilic scheduler preconditions for the 
COMMIT operation, there must be a return operation for T in a, a contradiction. 

2. Since T is live in a, CRKATFXT) occurs in a and so Lemma 13 implies that 
RKQUKST— CRKATFXT) occurs in a. The result then follows from part 1. 

3. Since there is no CRKATKTT) in a, there can be no RKQUKST-COMMIT for T, by 
well-formedness. Then there can be no COMMIT for T, by the scheduler preconditions. 
The result follows from part 1. 



l/cmma 18: 1 ,ct a be a well-formed serial schedule, and let T be a transaction. 

1. If a contains a RKQUKST- CRKATFXT) but docs not contain a return operation for T, 
then any proper ancestor of T is live in a. 

2. If T is live in a, then any ancestor of T is live in a. 

3. If a contains a RKQUKST-CRKATK(T) but docs not contain a CRKATKCT) or an 
ABORT(T), then any proper ancestor of T is live in a. 

Proof: By repeated use of Lemma 17. I 

Lemma 19: Let o be a well-formed serial schedule, and let T and T be transactions with T a 
descendant of T. Assume that there is a COM M IT operation for T in a. 

1. If a RKQUKST- CRKATFXT) occurs in a, then there is a return operation for T in a. 

2. If T is in transaction(a), then there is a COMMIT operation for T in a. 
Proof: 

1. By Lemma 18. 

2. Lemma 13 implies that RKQUKST- CRKATFXT') occurs in a. Part 1 then implies that 
there is a return operation for T in a. Since T is in transaction(a), Lemma 16 implies that 
there cannot be an ABORT( T) in a. 'ILius, there is a COMMIT for T in a. 

I 

Ixmma 20: Let a be a well-formed serial schedule. 
If a return operation for T is in a, then it follows all operations in a whose transaction is T. 

Proof: Lemma 16 implies the result if an ABORT(T) occurs in a. So assume that a COMMIT 
for T occurs in a. 'This must be preceded by a RKQUKST-COMM1T for T, by scheduler 
preconditions. Well-formedness implies that the RKQUKST— COMMIT is preceded by a 
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CRLATH(T). and is not followed by any output operations of 'I'. Thus, the only operations of T 
that could follow the RI'QUKST-COMMIT arc return operations for children off. Let T be a 
child of'T for which a return operation occurs in a. Hy scheduler preconditions, there is only one 
return operation for 'I" in «. Uy Lemma 13. a also contains a RLQUKST— CRKATIXT). Since 
this is an output operation off, it precedes the RLQUKST -COM MIT for T, and hence precedes 
the COMMIT for T. Then the scheduler preconditions imply that the return operation for T 
precedes the COMMIT for T. I 

Lemma 21: I .ct a be a well-formed serial schedule. 
If a return operation for T is in a. then it follows all operations in a whose transactions arc 
descendants of T. 

I'roof: Since a return operation for T occurs in a, we have T * l' . I ct 'I" be a descendant of T, 
and assume for the sake of obtaining a contradiction that an operation w with transaction(w) = T 
occurs after the return for T in a. Let a be the prefix of a preceding w. 

Lemma 16 implies the result if an AIJORT(T) occurs in a. So assume that a COMMIT for T 
occurs in a. Uy Lemma 13, a contains a RLQUKST- CRKATK(T') operation. Then Lemma 19 
implies that a contains a return operation for T. Hut then the well-formed schedule an contains 
a return for T followed by an operation of T, which contradicts Lemma 20. I 

Lemma 22: 1 .ct a be a well-formed serial schedule. If T is a pending access in a|X, then T is live 
in a. 

I'roof: If T is a pending access in cr|X, then a CRKAIKfT) occurs in o, but no 
RKQUKST— COMMIT for T occurs in a. Thus, by the scheduler preconditions, no COMMIT 
for T can occur in a. I 

licmmu 23: Let o be a well-formed serial schedule, and let T and T be distinct transactions live 
in a. Then the following arc true. 

1. T and T arc not siblings. 

2. Either T is an ancestor of T or vice versa. 
Proof: 

1. Assume the contrary. Assume without loss of generality that CRKATLX'I) precedes 
CRKATFX'I") in a. Then the scheduler preconditions for the CRHATLXl") operation 
imply that a return operation for T occurs in a. This contradicts the assumption that T is 
live in a. 

2. By part 1 and Ixmrna 18. 



3.6.3. Well-Formedness 

Now we show that all serial schedules are well-formed. It follows that all the properties proved in the 

previous paragraph for well-formed serial schedules are actually true for all serial schedules. Subsequently, 

we will use these properties without explicitly mentioning well-formedness. 

Ix-mma 24: Let a be a serial schedule. Then a is well-formed. 

Proof: Hy induction on the length of schedules. The base, length = 0, is trivial. Suppose that 
aw is a serial schedule, and assume that a is well-formed. If -n is an output of a primitive P, then 
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ow|P is well-formed because I' preserves well-formedness, and so air is well-formed. So assume 
that n is an input to a primitive 1'. It suffices to show that «w|P is well-formed. There arc four 
cases. 

(1) it isCRKA TIX 'I') and T is a non-access transaction. 

The scheduler preconditions insure that CRKA'ITX'C) docs not appear in a. 

(2) w isCOMMI T(T,v) for sonic transaction T and value v. 

Then tt is an input to transaction parcntCI") = I". The scheduler preconditions imply that a 
contains a RHQUKST — COMMIT(T,v). and so Lemma 13 implies that a contains a 
RKQUKS'i -CRHA I K(T). Also, the scheduler preconditions imply that no return operation for 
T occurs in or. 

(3) it is ABORT(T) for some transaction T. 

Then w is an input to transaction parcntCI") = T\ The scheduler preconditions imply that a 
contains a RKQUKST-CRKATK(T), but no return operation for T. 

(4) it is CRKATTXT) and T is an access to basic object X. 

By die scheduler preconditions, no CRKATTXT) or ABORT(T) appears in a, but a 
RKQUKS T— CRHA TK(T) appears in a. Assume for die sake of deriving a contradiction that T is 
a pending access in a\X. Then I .emma 22 implies that T is live in a. Also, Lemma 17 implies that 
parcnt('l') is live in a. Then Lemma 23 implies that one of T or parcnt(T) is an ancestor of the 
other; since T and 'I" arc both leaves of the transaction tree, the only possibility is that parcntCI") is 
a proper ancestor of T. I .ct T" be the sibling of T which is an ancestor of 'I". Then T" is live in a, 
by Lemma 18. That is, there is a CRKATKCD, but no COMMIT for T" in a. But this 
contradicts the scheduler preconditions for v. ITicrcforc, there is no pending access in a\X. I 

3.6.4. Visibility and Serial Schedules 

In this paragraph, wc prove interesting lemmas about visibility in serial schedules. 

Lemma 25: Let a be a serial schedule, and -n an operation in a. Ilicn transaction(w) is visible in 
a to some transaction which is live in a. 

Proof: I .ct T = transaction^). Since a is not empty, T is live in a. I .ct T be the least ancestor 
of T which is live in a. ITic proof is by induction on the distance from T to T. If T = T, the 
result is trivial. So assume that T * T. I"hcn COMM 11(1) is in a, and so T is visible to parcnt(T) 
in a. Lemma 13 implies that a contains a RKQUKST-CRKATHX'O operation, which occurs at 
parcnt(T). Then the inductive hypothesis implies that parcntCI") is visible to 1". Then T is visible 
toT by Lemma 8. I 

(.emma 26: 

1. Let a be a serial schedule, T a transaction and X an object Then visib!c(a,T)|X is a prefix 
ofa|X. 

2. Let a be a serial schedule, T a transaction and P a primitive. Then visiblc(a,T)|P is a prefix 
ofa|P. 

Proof: 1. Let ir and <p be operations in o|X, with w preceding qp, and <p an operation in 
visibIc(a,'T). Let a' be the prefix of a preceding (p. Let T = transaction(<p) and T" = 
transaction^). Since <p is cither a CRKATK or a RKQUKS T- COMM IT for T, well-formedness 
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of a implies that 'I" is live in «'<p. Thus, by Lemma 23, the only live transactions in a'<p arc 
ancestors of 'I". Hy Lemma 25. T" is visible to an ancestor of" T* in a'q>. and hence in a. By 
Lemma 8. T" is visible to T in a. lint T is visible to T in a. by assumption. Lemma 8 then 
implies that T" is visible to T in a, which gives the result. 

2. Immediate from Lemma 11 and part 1. I 

Lemma 27: Let a be a nonempty serial schedule. Let it be the last operation in a which is an 
output of the serial scheduler. Then transaction m) sees everything in a. 

Proof: Let T = transaction tt). Wc first show that T is live in a. Hither it is a CRKATK(T) or 
else it is a return operation for a child T of T. In the latter case. Lemma 14 implies that 
CRKATL(T) also occurs in a. Thus, in cither case, CRKA TK( T) occurs in a. Now, if a return 
operation for T occurs in a. Lemma 21 implies that it follows it, which is impossible. Thus, no 
return operation for T occurs in o. It follows that T is live in a. 

Iticn Lemma 23 implies that the only other transactions that arc live in a must be ancestors or 
descendants of T. Wc claim that no proper descendants of T arc live in a. So assume for the sake 
of obtaining a contradiction that U is a proper descendant of 'I' which is live in a. Ilicn U is a 
descendant of a child V of T, and V is live in a, by Lemma 18. Let of be the prefix of a preceding 
w. There arc three cases. 

(1) 7T isCRKATK(T). 

Then Lemma 14 yields a contradiction. 

(2) it is a COMMIT operation for T\ a child ofT. 

Then T * V, since T is not live in a. But T and V arc both live in a\ which contradicts Lemma 
23. 

(3) -a is an ABORT(T), for child T of T. 

Then T * V, since T is not live in o. But V is live in a. But then the scheduler preconditions for 
•n arc not satisfied, a contradiction. 

Thus, no descendants arc live in o, so the only transactions that arc live in a arc ancestors of 
T. Now let <p be any operation in a. Lemma 25 implies that transaction(qp) is visible in a to some 
ancestor of T, and hence to T. I 

kmma 28: Let a be a serial schedule, and T a transaction. Then visible(a,T) is a serial 
schedule. 

Proof: Wc proceed by induction on the length of a. The basis, length 0, is trivial. Let a - am, 
where it is a single operation. Fix transaction T, and let V = transaction(w). If T' is not visible to 
T in a, then visib!c(a,T) = visiblc(a',T), and the result is true by inductive hypothesis. So assume 
that T is visible to T in a. 

If it is an output operation of a primitive P, then visiblc(a,T)|P is a prefix of a|P, by Lemma 26, 
and thus is a schedule of P. By the inductive hypothesis, visible(a',T) is a serial schedule. Also, 
visiblc(a,T) = visiblc(a\T)w by Lemma 12. Then Lemma 4 shows that visiblc(a,T) is a serial 
schedule. 

On the other hand, if w is an output operation of the scheduler, then Lemma 27 implies that T 
sees everything in a. But since T is visible to T in o, it follows that T sees everything in a. Thus, 
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visiblc(a,T) = a, a serial schedule. I 

3.6.5. Reordering and Combining Serial Schedules 

In this paragraph, wc describe ways in which serial schedules can be modified and combined to yield other 
serial schedules. These lemmas arc used in the proof of the main theorem, in Section 7. 

lemma 29: Let a and a' be two equivalent serial schedules. If/? is a sequence of serial 
operations such that afi is a serial schedule, then afi is a serial schedule, and is equivalent to afi. 

Proof: Kquivalcncc is trivial. The fact that afi is a serial schedule follows because the 
preconditions of the serial scheduler depend only upon the presence of previous operations, not 
their order. I 

The next lemma says that any serial schedule can be transformed by moving all the operations visible to any 
particular transaction to the beginning of the schedule, and the result is another serial schedule. ITiis lemma 
can be thought of as describing a kind of "canonical form" for a serial schedule, with respect to a particular 
transaction. 

lamina 30: Let a be a serial schedule, and T any transaction. Let fi — visiblc(a.T). Then fi(a - 
fi) is equivalent to a and is serial. 

Proof: Let a = fi(a - fi). If P is any primitive, then Lemma 26 implies that fi\P is a prefix of 
«|P. ITius, o' is equivalent to a. 

To show that a is serial, wc proceed by induction on its prefixes. liy Lemma 28, fi is serial, so 
wc can use fi as the basis. I .ct y v be a prefix of a', where w is a serial operation in a - fi and y is a 
serial schedule. If w is an output operation of a primitive P, then yw|P is a prefix of a'|P, = a|P 
by equivalence, which is a schedule of P. Then Lemma 4 shows that yn is a serial schedule. So 
assume that v is an output operation of the serial scheduler. 

Lets be the state of the serial scheduler after y. LctyV be the prefix of a ending in w, and lets' 
be the state of the serial scheduler after y\ Then ir is enabled in s'. Wc must show that it is 
enabled in s. This suffices, by Lemma 4. 

Since every operation in y' is also in y, it follows that each component set of s' is a subset of the 
corresponding set of s. There arc three cases. 

(1) m is CRKAThXT) for some transaction T. 

Then transaction^) = T, and T is not visible to T in a. Then V € create — rcqucstcd(s') C 
create — rcqucsted(s). Also, it is easy to show that 'I" € crcatcd(s). Now let U be in siblings(T) D 
crcatcd(s). If U € crcatcd(s'), then U € rcturncd(s') since ir is enabled in s\ C rcturncd(s). as 
needed. So suppose that U £ crcatcd(s'). Then CRHAThXU) occurs in fi, so U is visible to T in a. 

Since a contains both CRHATK(T) and CRHATH(U), Lemma 23 implies that a must contain a 
COMMIT for at least one of T or U. If a contains a COMMIT for U, then it occurs in fi, so U € 
rcturncd(s). On the other hand, if a contains a COMMIT for T, then T is visible to U in a, so 
Lemma 8 implies that T is visible to T in a, a contradiction. 

(2) v is COMMIT(T,v) for some transaction T and value v. 
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Then transaction^) is parcnl('l"), which is not visihlc to T in a. Then (T,v) is in 
commit- requesters") C commit- rcqucsled(s). Also, it is easy to show that T is not in 
rcturncd(s). Now let U he in childrcn( I") n create- rcquested(s). Then there is a 
RLQULS'I -CKI'A I H(U) in y. This RI.QULST-CRLATIXU) occurs at I ", which cannot be 
visible to I in « since parcntO") is not visible to '!' in a. Thus, the RLQULST-CRLAITXU) 
docs not occur in /?. so it occurs in y\ Since it is enabled in s\ we have U € rcturncd(s') C 
rcturncd(s). 

(3) it is AllOR T( I") for some transaction T. 
Then transaction^ ) = parcnl(T), and parcnt(T) is not visible to T in a. Then T € 
create- rcqucstcd(s') C create- rcqucsted(s). Also, it is easy to show that 1" £ crcatcd(s). Now 
let U € siblings* T) D crcated(s). Then CRKATK(U) occurs in y. Hut CRKATK(U) occurs at U, 
and U cannot be visible to T in a since parent(U) = parcnt(T) is not visible to T in a. Therefore, 
CRLAITXU) docs not occur in 0, so it occurs in y'. Then U is in siblings* I") n crcatcd(s') C 
rcturncd(s') C rcturncd(s). I 

ITic following lemma is an easy consequence of the preceding one. 

tamma 31 : I .ct a be a schedule of serial operations, and let T and T be two transactions with T 
visible to I in a. I .ct P and /T be serial schedules, such that P is equivalent to visiblc(o.T) and /T 
is equivalent to visiblc(a, T'). I'hcn /T = /?'(/? - P') is equivalent to /? and serial. 

Proof: Let y = visiblc(/?,T). Then y is serial by Lemma 28. Lemma 30 implies that y(fi - y) is 
equivalent to /? and serial. I .emma 10 implies that /?' is equivalent to y, and thus that /J - y = fi - 
ft'. Then Lemma 29 implies that p" is equivalent to y(/? - y) and serial. Thus, /3" is equivalent to 
P and serial. I 

The next two lemmas arc used in the proof of ITicorcm 68. Kach describes a way of "cutting and pasting" 

two serial schedules to yield a new serial schedule. 

Umma 32: Let a/^COMMITfX.ii) and ap 2 be two serial schedules and T, T and T" three 
transactions such that the following conditions hold: 

( 1 ) T is a child of T' and T is a descendant of T" but not of T, 

(2) I" sees everything in aP v 

(3) T sees everything in ot/? 2 , 

(4) a = visiblc(a/3,,'l") = visibMa^jT') and 

(5) no basic object has operations in both p { and $ r 
Then a/^COMMITCP.u)/^ is a serial schedule. 

Proof: Note first that if T = T", then P 2 is empty and the result is trivial. So assume that T * 
T\ Then T is a descendant of a child U of T", and U * T. 

Any operation in aP [ whose transaction is not a descendant of T, must be in visiblc(a/3 1 ,T') by 
Lemma 8. Similarly, any operation in a/? 2 whose transaction is not a descendant of U, must be in 
visibIc(a/? 2 ,T"). Thus, /?, and P 2 contain only operations at descendants of T and U, respectively. 
Since T and U arc distinct siblings, and by assumption no objects have operations in both P 1 and 
/?,, it follows that no primitive has an operation occurring in both P x and P 2 - 

We proceed by induction on prefixes of a/5,COMMIT(T.u)/8 2 . Let a> be a prefix of 
aP 1 COMMri'('l".u)/3 2 , with a a serial schedule and <p a serial operation. We use a> = 
a/3.CO!vlMIT(T\u) as the basis, since a^,COMMIT('l",u) is a serial schedule by assumption. So 
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assume thai a' = a/LCOMIVHT(T,u)/?' for some sequence ft'. There arc two cases, depending 
on whether <p is an output of a primitive or of the serial scheduler. 

Suppose that <p is an output operation of a primitive P. Then /^COMMII'O'.v) contains no 
operations at P. Thus, a'tp|P = aft'<p\\\ which is a prefix of a/J ? |P. which is a schedule of P since 
aft, is a serial schedule. Thus, a'<p|P is a schedule of P. The result follows by I.cmma4. 

So suppose cp is an output of the serial scheduler. Then transaction(<p) = V for some 
descendant V of U. I.ct s be the slate of the serial scheduler after a, and let s' be the state of the 
serial scheduler after aft'. Then the following relationships hold between s and s'. 

1. V € create- rcqucstcd(s') - crcatcd(s') iff V € create- rcqucstcd(s) - crcatcd(s) 

2. childrcn(V) D create- rcqucstcd(s') C rcturncd(s') iff childrcn(V) D create- rcqucstcd(s) 
C rcturncd(s) 

3. (V,v) € commit - rcqucstcd(s') iff (V,v) € commit- rcqucstcd(s) 

4. V C rctumcd(s') iff V € rctumcd(s) 

5. siblings(V) D crcatcd(s') C rcturncd(s') iffsiblings(V) fl crcatcd(s) C rcturncd(s) 

Since the operations in ft^ arc all at descendants of T, and those of ft 2 arc all at descendants of 
U, the first four biconditional arc immediate from lemma 7. If V is a proper descendant of U, 
the last biconditional also follows. It remains to show that siblings(U) D crcatcd(s') C rcturncd(s') 
iff siblings(U) f~l crcatcd(s) C rcturncd(s). Hut any sibling of U created in aft' is created in a\ 
and the only sibling of U created in a and not aft' is T, and T € rcturncd(s). Thus, the claims 
arc true. 

Since <p is enabled in s\ the claims above imply that <p is also enabled in s. The result follows. I 
Lemma 33: I.ct aAUORT(T) and aft be two serial schedules, and let T, T and T" be 

transactions, such that the following conditions hold: 

(1)T is a child of T" and T is a descendant of T" but not of T, 

(2) I sees everything in aft, and 

(3) a = visible(a.r) = visiblc(a0,T"). 
Ilicn oABOIM'('l")/3 is a serial schedule. 

Proof: Similar to, but somewhat simpler than, the proof of Lemma 32. I 

4. Resilient Objects 

Having stated our correctness conditions, we are now ready to begin describing implementations and 
proving that they meet the requirements. i"his section and the next arc devoted to the description of a 
concurrent system which permits the abort of transactions that have performed steps. An important 
component of a concurrent system is a new kind of object called a "resilient object," which we introduce in 
this section. A resilient object is similar to a basic object, but it has the additional capability to undo 
operations of transactions that it discovers have aborted. 



25 



Resilient objects have no capabilities for managing concurrency: rather, they assume that concurrency 
control is handled externally (by lock manager components of the scheduler). This section defines resilient 
objects and presents some of their properties. It also digresses slightly from the main development by 
describing and proving correct a particular implementation of resilient objects, which arc constructed by 
keeping multiple copies of corresponding basic objects. The resilient object manages these copies as versions 
of the data object. Upon learning of an abort, the appropriate stored version is used in place of the current 
version. 

4.1. Definitions 

Resilient object R(X) mimics the behavior of basic object X, but has two additional input operations, 
INFORM-COMMIT-A'KX)OF(T) and INFORM- ABORT- AT(X)OF(T), for every transaction 
T. Upon receiving an INFORM -ABORT- A T(X)OF(T), R(X) erases any effects of accesses which arc 
descendants of T. Itiis property is made formal as the "Resiliency Condition" below. 

R(X) has the following operations, which wc call R(X)-operations. 

Input Operations: 

CRKATK(T), T an access to X 
INFORM -COMMIT- AT(X)OF(T) 
INFORM - ABORT- AT(X)OF(T) 

Output Operations: 

RHQUKS T-COMMIT(T,v), T an access to X 

In order to describe well-formedness for resilient objects, wc require a technical definition for the set of 
transactions which arc active after a sequence of R(X)-opcrations. Roughly speaking, the transactions which 
arc active arc those on whose behalf the object has carried out some activity, but whose fate the object does 
not know. 

The definition is recursive on the length of the sequence of R(X) operations. Namely, only T Q is active after 
the empty sequence. Let a = fiv, where w is a single operation, and let A and B denote the sets of active 
transactions after a and 0, respectively. If it is CRKATK(T), then A = B U {T}. If w is a 
RHQUESI -COMMIT forT, then A = B. If v is 1NFORM-COMMIT- AT(X)OF(T), and if T is in B, 
then A = (B - {'!'}) U {parcnt(T)}; ifT is not in B, then A = B. If it is INFORM-ABORT- AT(X)OF(T), 
then A = B - dcsccndants(T). 

Now wc define well-formedness for sequences of R(X) operations. Again, the definition is recursive. 
Namely, the empty schedule is well-formed. Also, if a = air is a sequence of R(X)-opcrations, then o is 
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well-formed provided that or' is well-formed, and the following hold. 

• Ifw isCRKATF(T), then 

(i) there is no CRFATKfO in a, 

(ii) all the transactions which arc active after a arc ancestors of T. 

• Ifw isaRFQUFST-COMMIT for T, then 

(i) there is no RFQUFS T-COMMI T forT in a\ and 
(ii) T is active after a'. 

• Ifw islNFORM-COMMIT-AT(X)OF(T),thcn 

(i) there is no INFORM- ABORT- AT(X)OF(T) in a\ and 

(ii) if'l is an access to X. then a RFQUFST-COMMIT for T occurs in a'. 

• Ifw is INFORM- ABORT-AT(X)OF(T), then 

(i) there is no INFORM -COMMIT- AT(X)OF(T) in a\ 

An immediate consequence of these definitions is that the transactions active after any well-formed 
sequence of R(X)-opcrations a arc a subset of tine ancestors of a single active transaction, which wc denote 
lcast(a). 

For a a sequence of R(X)-opcrations, define undo(a) recursively as follows. Define undo(X) = X, where A 
is the empty sequence. Let a = p-n, where w is a single operation. Ifw is a serial operation (a CREATE or a 
RKQUF.ST-COMMIT), then undo(a) = undo(y8)w. Ifw is INFORM -COMMIT- AT(X)OF(T), then 
undo(a) = undo(/?). Ifw is INFORM - ABORT- A T(X)OF(T), then undo(a) is the result of eliminating, 
from undo(/3), all operations whose transactions arc descendants of T. Note that undo(a) contains only serial 
operations. 

Let a be any sequence of R(X)-opcrations, and let ir be an operation in a of the form 
INFORM -ABORT- AT(X)OF(T). 'Ilicn the scope of v in a is the subsequence y of a consisting of 
operations eliminated by v. 

Resiliency Condition 

Resilient object R(X) satisfies the resiliency condition if for every well-formed schedule a of R(X), undo(a) is 
a schedule of basic object X. 

We require that resilient object R(X) preserve well-formedness and satisfy the resiliency condition. 

The resiliency condition is the correctness condition required by the concurrent schedulers at the object 
interface. The well-formedness requirement is a syntactic restriction, and the condition that undo(a) be a 
schedule of basic object X expresses the required semantic relationship between the resilient object and the 
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basic object it incorporates. The important property which must be preserved is thai the correctness condition 
at the resilient objects, together with die behavior of the concurrent scheduler, assures correctness at the 
transaction boundaries. 

4.2. Properties of Resilient Objects 

This subsection contains a collection of simple lemmas about the properties of well-formed sequences of 
R(X) operations. 

Lemma 34: let am be a well-formed sequence of R(X) operations, with ir a single operation. 
The following arc true. 

1. If it is a serial operation, then transaction^ ) is active after air. 

2. If T is an access active after a prefix of a but not after a, then T is not active after av. 

3. If ir is a RHQUFST-COMMIT for T. then CRFATF(T) is the last serial operation in a. 
Proof: 

1. Immediate from the definition of active and well-formedness. 

2. Because T has no descendants, it can only become active when a CRFATFXT) operation 
occurs, which can only happen once in a well-formed schedule. 

3. Suppose the last serial operation in a is 9, with 9 * CRFATFXT). Let transaction^) = 
T\ By well-formedness, T * T. Also by well-formedness. T is active in a, so that 
CRFATFXT) must occur in a, and so precedes 9. By part (1), T is active following 
CRFATFXT) and after w, and T is active following 9. But T cannot be active when 9 
occurs, by well-formedness, contradicting part (2) of this lemma. 

I 

Lemma 35: Let a be a well-formed sequence of R(X) operations. Let T and T be accesses to X, 
with T * I", and let it and 9 be serial operations with transactions T and T, respectively. If it 
precedes 9 in a, then between m and 9, there is cither an INFORM — ABORT— AT(X) for some 
ancestor of T, or else there are INFORM -COMMIT- A T(X)OF(U) operations for all ancestors 
U of T which are not ancestors of T, occurring in order from lowest to highest in the transaction 
tree ordering. 

Proof: By part 3 of Lemma 34 and well-formedness, we may assume that 9 = CREATFXT). 
Lemma 34 implies that T is active immediately after it. By well-formedness, before CRF.ATK(T) 
can occur, it must be that all transactions which arc active are ancestors of T. There arc only two 
ways in which this can happen. One possibility is that R(X) first receives INFORM — COMMITS 
for all ancestors of T up to lca(T,T), in order from lowest to highest in the transaction tree 
ordering. The other possibility is that R(X) first receives an INFORM- ABORT for an ancestor 
of T. I 

Ixmma 36: Let aw be a well-formed sequence of R(X) operations, with ir = 
INFORM -ABORT- AT(X)OF(T). Then undo(aw) is a prefix of undo(a). 

Proof: Suppose not. Then there is a subsequence 9^ of two operations in undo(a). such that \p 
is in undo(air) and 9 is not. Clearly, 9 and ^ arc serial operations, transaction^) is a descendant 



28 



of T and transaction^) is not. Since <p is not in the scope of an INFORM- AMOR T in a, by 
lemma 35, there is an INFORM -COMMIT between <p and \p for every proper descendant of 
lca(trans;iction((jp),transaction(>/')) that is an ancestor of transaction^ ), including T. This 
contradicts the well-formedness of aw. I 

Lemma 37: Let a be a well-formed sequence of R(X) operations, and let T be any transaction 
active in a, other than T„. Then undo(a) contains an operation <p at a descendant 1" of T, which is 
followed in a by an INFORM -COMMIT for every ancestor of T which is a proper descendant 
ofT. 

Proof: The proof is by induction on o, with a trivial basis. I.cl a = aV, such that the lemma is 
true for a' and that m is a single operation. Let T be a transaction active after a. There arc four 
cases. 

Suppose w is CRRATF(T"). Then undo(ct) = undofcOw. If'T * T". the result is immediate by 
the induction hypothesis, since T is active after a. If T = T", then the lemma follows, with w = 

<P- 

If w is a RFQUFST-COMMIT for a transaction T", then undo(a) = undo(a')w and the same 
transactions arc active in a and a'. The result is immediate. 

Suppose w is an INFORM -COMM IT for a transaction T'. Then undo(a) = undo(a')w. IfT 
is active after a\ the result is immediate. IfT is not active after a\ it follows that T = parcnt(T"). 
The result is immediate from the induction hypothesis. 

Suppose w is an INFORM - AMORT for a transaction U. Since T is active after a, it was active 
after a and U is not an ancestor of T. Let <p be the transaction of transaction 1" which follows 
from the inductive hypothesis applied to T and a'. Since a is well-formed and a contains 
INFORM -COMMITS for every ancestor of T up to T, U is not an ancestor of T. It follows that 
<p is in undo(a) and the result holds. I 

IvCinma 38: Let a be a well-formed sequence of R(X) operations, and let lcast(a) = T. If 
undo(a) is nonempty, then it ends in an operation of a descendant of T. 

Proof: IfT = T», the result is trivial, so assume otherwise. By the previous lemma, undo(a) 
contains an operation <p at a descendant of T. Without loss of generality, assume that 9 is the last 
operation in undo(a) at a descendant of T. If any other operation it followed <p in undo(a), by 
Lemma 35 a would contain INFORM -COMMITS for every ancestor of transaction^ ) up to 
lca(transaction(<p),transaction(w)), which includes T. Then T is not active in a, a contradiction. I 

Lemma 39: Let aw be a well-formed sequence of R(X) operations, with v = 
INFORM -ABORT- A T(X)OF(T). if T is not an ancestor of lcast(a), then undo(aw) = 
undo(a). 

Proof: Suppose that T is not an ancestor of lcast(a) and that undo(aw) * undo(a). Then 
undo(a) contains a serial operation <p at a descendant T of T. By Lemma 38, <p is followed in 
undo(a) by an operation at a descendant of lcast(a). By Lemma 35, a contains an 
INFORM -COMMIT for every ancestor lcast(cc) up to lca(lcast(a),T'), which includes T, 
contradicting the well-formedness of aw. 

We arc now able to show that the undo operator preserves well-formedness. 

Lemma 40: If a is a well- formed sequence of R(X)-opcrations, then undo(a) is a well-formed 
sequence of X-opcrations. 
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Proof: The proof is by induction on the length of a. The basis is trivial. Assume a = ait, 
where m is a single operation, and undo(a') is a well-formed sequence of X -operations. If w is an 
INKORM-ABORTor INFORM -COMMIT, undo(a) is a prefix of undo(a*), by Lemma 36. and 
the result is immediate. 

If w is CRKAITXT). then undo(«) = undo(a')7r. By the well-formedness of a, CRKATKXT) 
docs not appear in «', and so not in undo(a'). Hence, (i) is satisfied. To sec (ii), assume that 
CRKA'ITXT') occurs in undo(a'), for access I". Then Lemma 35 implies that 
INI-ORM-COMMIT-AT(X)OK(T') occurs after CKLATL(T') in o. Then well-formedness 
(the precondition for INFORM-COMMTI - A T(X)OF( I ")) implies that a 
RKQUKST— COMMIT for T occurs in a, and well-formedness also implies that the 
RKQUKST -COM MIT for 1" follows the CRKATKXT'). Therefore, the RKQUKST- COM MIT 
occurs in undo(a'), and so T is not pending in undo(a'). Thus, (ii) is satisfied. 

If v is a RKQUKST-COMMIT for T, then again undo(a) = undo(a')w, and by the well- 
formedness of a, (i) no RKQUKST— COMMIT for T appears in a\ and so not in undo(ot'), and 
(ii) T is active after a\ and it follows that CRKATKXT) occurs in undo(a'). I 

4.3. Construction of a Resilient Object 

In this subsection, we describe a construction of a resilient object R(X) from a basic object X. 

Recall that a resilient object X is distinguished from a basic object in that it has INFORM -AMORT and 
INFORM-COMMIT operations, a different definition of well-formedness, and satisfies the resiliency 
condition. The resilient object R(X) is constructed from the states, transition function and operation labels of 
the basic object X. The resilient object R(X) maintains a collection of "copies of X" (i.e. remembers states of 
X), one for each active transaction, with a particular current copy (corresponding to the least active 
transaction) to which CRKATK operations arc sent. When R(X) receives an INFORM -ABORT, the 
appropriate stored copy becomes the current copy, thereby erasing the effects of the operations in the scope of 
the INFORM -ABORT. 

The state of R(X) consists of a pair (act,map), where act is a set of "active" transactions, and map is a 
function from act to states of basic object X. In the well-formed executions of R(X) (defined below), act will 
always be a subset of the set of ancestors of one particular transaction in act, called lcast(act). (In case act has 
no least member (which, again, will not arise in executions with well-formed schedules), define least(act) 
arbitrarily.) The copy for lcast(act) is considered to be current. The initial states of R(X) arc those in which 
act = {T Q } and mapOrJ is an initial state of the basic object X. In the following specification of the 
operations of R(X), let (act'.map') be the state of R(X) prior to the operation, and (actjnap) be the state of 
R(X) after the operation. 

• CRKATKXT), T an access to X: 
Postcondition: 
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act = act' U {T} 

map(U) = map'(U) for all U € act - {T\ 

map('I') = s, where (map'(lcast(act')),CRKATIv(T),s) is in the transition relation of X 

• INIORM- ABORT- AT(X)OP'(T): 
Postcondition: 

act = act' - {descendant^ T)} 
map(U) = map'(U) for all U € act 

• INrORM-COMMIT-AT(X)OF(T): 
Postcondition: 

if T € act' then 

begin 

act = (act' - {'I'}) U {parcnt(T)} 

map(U) = map'(U) for U € act - {parcnt(T)} 

map(parent(T)) = map'(T) 

end 

if T <£ act' then act = act' and map = map' 

• RFQUKST-CO!v1lv1lT(T,v): 
Precondition: 

lcast(act') = T 

(map'(T),RKQUKST-COMMIT(T,v),s) is in the transition relation of X 

Postcondition: 

act = act' 

map(U) = map'(U) for all U € act - {T} 

map( T) = s 

Now wc prove that this implementation is a correct resilient object 

Ix'inma 41: Let a be a well-formed schedule of R(X) which can leave R(X) in state (act,map). 
Then act coincides with the set of transactions which arc active after a. 

Proof: The proof is by induction on the length of a. ITic basis is trivial. Let a = a'w, where ir 
is a single operation. There arc four cases, depending on the type of operation w. Each is 
immediate from the definition of active and the implementation of R(X). I 

IxMiima 42: Let a be a well-formed schedule of R(X) which can leave R(X) in state (act,map). 
Then the following conditions hold. 

• undo(a) is a schedule of basic object X which can leave X in state map(lcast(act)), and 

• if T is any transaction other than T , and oINFORM- ABORT- AT(X)OFfr)) is well- 
formed, then undo(aINFORM - ABORT- AT(X)OF(T')) is a schedule of basic object X 
which can leave X in state map(U), where U is the least clement of act which is not a 
descendant of T. 

Proof: First, observe that if T is not an ancestor of lcast(act), and 
alNKORM- ABORT- AT(X)OK(T') is well-formed, then Lemmas 41 and 39 imply that 
undo(olNFORM- ABORT- AT(X)OF(T')) = undo(a), so the second condition follows from 
the first. 



31 



The proof is by induction on the length of o. In each case, wc prove the first condition, then the 
second condition assuming that T is an ancestor of lcasl(act). By the observation above, this is 
sufficient. 

The basis is trivial. Let a = av, where n is a single operation. Let (act'.map') be a state of 
R(X) after a\ such that ((act',map'),7r,(act,map)) is a transition for R(X). There arc four cases. 

1) it = CRKATK(T) 

Then undo(a) = undo{a')w. By the inductive assumption, undo(a') is a schedule of X which can 
leave X in state map'(lcast(act')). Uy the implementation of R(X), (map'(lcast(act')),7r,map(T)) is a 
transition of X, and I = lcast(act). Thus the first condition of the lemma is satisfied. 

To sec that the second condition holds, note that all active transactions after a arc ancestors of T, 
and by well-formedness, arc exactly the transactions active after a\ together with T. Let <p be 
INFORM- ABORT-A T(X)OF(T'), where T' is an ancestor of T other than l' , and a<p is well- 
formed. If T is a proper descendant of lcast(act'), by I .emma 39, undo(oqp) = undo(a'), which is 
a schedule of basic object X which can leave X in state map(lcast(act'))), by the inductive 
hypothesis. If T is an ancestor of lcast(act'). undo(a<p) = undo(a'<p), the least clement of act 
which is not a descendant of I" is also the least clement of act' which is not a descendant of 1", and 
the result follows by the inductive hypothesis. 

2) ir = RFQUFST-COMMIT(T,v) 

Then undo(a) = undu(a')iT . By the inductive assumption, undo(a') is a schedule of X which can 
leave X in state map'(lcast(act')). Uy the implementation of R(X), (map'(lcast(act')),w,map(T)) is a 
transition of X, and T = lcast(act). Thus the first condition of the lemma is satisfied. 

To see that the second condition holds, note that the active transactions after a arc all ancestors 
of T. and by well-formedness, arc exactly the transactions active after a'. Let <p be 
INFORM- ABORT- A T(X)OF(T'), where T is an ancestor of T other than I' , and a<p is well- 
formed. Then undo(a«p) = undo(a'<p), which is a schedule of basic object X which can leave X in 
state map(lcast(act'))), by the inductive hypothesis. Furthermore, the least clement of act which is 
not a descendant of T is also the least clement of act' which is not a descendant of T, and the 
result follows by the inductive hypothesis. 

3)w = INFORM -COMMIT- AT(X)OF(T) 
'linen undo(a) = undo(a'). Also, map(lcast(act)) = map(least(act')), by definition of R(X). The 
first condition follows. 

By the definition of R(X), lcast(act) is an ancestor of lcast(act'). Let <p be 
INFORM - A BOR T- A T(X)OF( T), where T is an ancestor of lcast(act) other than T Q . and atp is 
well-formed. Then a<p is well-formed, and undotaqp) = undo(cr'<p). Also, since cup is well- 
formed, T * T. Let U and U' be the least elements of act and act', respectively, which arc not 
descendants of T. 

If T $ act', or if U * parcnt(T), then U = U' and map(U) = map'(U'), and the second 
condition follows from the inductive hypothesis. So assume that T € act' and U = parcnt(T). 
Then since T * T, it follows that U' = T. Then map'(U') = map(U), and the second condition 
again follows from the inductive hypothesis. 
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4)w = INFORM- ABORT- AT(X)OF(T) 
If T is not an ancestor oflcasi(act'), then undo(a) = undo(«'), by Lemma 39. Furthermore, the 
state of R(X) is not changed. oINFORM- ABORT-AT(X)-OF(T) is well-formed only if 
a'INFORM- AMORT- A T(X)-OF(T) is, and tlic active transactions after a arc exactly those 
active after a'. The result follows. 

Suppose that T is an ancestor of lcasl(act'). 'ITic first condition is immediate from the inductive 
hypothesis. Let <p be INFORM- ABORT- AT(X)OF(T). where T is an ancestor of lcast(act) 
other than T„, and a<p is well-formed. Since act = act' - dcsccndants( T), lcast(act), and hence I", 
is an ancestor of T, undo(a<p) = undo(a'ir<p) = undo(a'<p), and the second condition follows as 
well. I 

Theorem 43: R(X) is a resilient object. 

Proof: We must show that R(X) preserves well-formedness and satisfies the resiliency condition. 
That R(X) satisfies the resiliency condition follows immediately from Lemma 42. 

Assume that a is a well-formed schedule of R(X) and ir is an output operation of R(X) enabled 
after an execution with schedule a. We must show that aw is a well-formed sequence of R(XF 
opcrations. 

Since -n is an output, it has the form RKQUHST-COMMITOLv) for some access T and value v. 
Let (act,map) be a state of R(X) after a, such that ir is enabled in (act,map). Clearly, m is an 
output of basic object X enabled from state map(least(act)). By Lemma 42, undo(a) is a schedule 
of basic object X which can leave X in state map(lcast(act))), so undo(a)w = undo(air) is a 
schedule of basic object X. 

Since X preserves well-formedness for basic objects, and by Lemma 40 undo(a) is a well-formed 
sequence of X-opcrations, undo(a) ends with the operation <p = CRF.ATF(T) and contains no 
other operations with transaction T. Let /3<p be the prefix of a ending in <p. Suppose first that a 
RFQUFST-COMMIT for T occurs in a. Since a is well-formed, <p is the only CRF.ATK(T) 
operation in o, and by Lemma 34, the second RFQUBST— CRFATK for T follows <p, and by the 
definition of undo, is in undo(cr) if 9 is, a contradiction. 

It remains to show that T is active after a. By Lemma 34, T is active after /3<p. No 
INFORM -COMMIT for T can occur after <p in a. since by well-formedness, there is no 
RFQUKST-COMMIT for T in a. Also, since 9 is in undo(a), no INFORM- ABORT for an 
ancestor of 'I' can occur after <p in o. Thus T is still active after a. I 

5. Concurrent Systems 

As with serial schedules in classical settings, our serial schedules contain no concurrency or resiliency and 
thus arc too inefficient to use in practice. Their importance is solely for defining correctness for transaction 
systems. In this section, we define a new kind of system called a concurrent system. The new system consists 
of the same transactions as in a serial system, a resilient object R(X) for every basic object X of the serial 
system, and a concurrent scheduler. 

Concurrent systems describe computations in which transactions run concurrently and can be aborted after 
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they have performed some work. Hie concurrent scheduler has the joint responsibility of controlling 
concurrency and of seeing that the effects of aborted transactions (and their descendants) become undone. 
Concurrent systems make use of the roll-back capabilities of resilient objects to make sure that ABORT 
operations in concurrent systems have the same semantics (so far as the transactions can tell) as they do in 
serial systems. 

Concurrent systems are defined in this section. In the next section, the more permissive "weak concurrent 
systems" arc defined. In Section 7, we prove that the schedules of concurrent systems arc serially correct, as a 
corollary of a weaker correctness property for the weak concurrent system. 

5.1. lvock Managers 

The scheduler wc define is called the concurrent scheduler. It is composed of several automata: a lock 
manager for every object X, and a single concurrent controller. The job of the lock managers is to insure that 
the associated object receives no CREATES until the lock manager has received abort or commit information 
for all necessary preceding transactions. This lock manager models an exclusive locking protocol derived 
from Moss* algorithm [Mo]. ITic lock manager has the following operations. 

Input Operations: 

INTERNAE-CREA TE( T), where T is an access to X 
INFORM -COMMIT- AT(X)OF(T), for T any transaction 
INFORM- ABORT- A T(X)OF(T), for T any transaction 

Output Operations: 

CRHATFX T), where T is an access to X 

The input operations INTERNAL- CREATE, 1NFORM-COMMIT and 1NFORM-ABORT will 
compose with corresponding output operations of the concurrent scheduler which wc will construct in this 
subsection. The output CREATK operation composes with the CREATE input operation of the resilient 
object R(X). The lock manager receives and manages requests to access object X, using a hierarchical locking 
scheme. It uses information about the commit and abort of transactions to decide when to release locks. 

Each state s of the lock manager consists of the following three sets of transactions: lock - holders(s), 
create - rcqucstcd(s), and crcatcd(s). Initially, lock -holders = {T }, and the other sets arc empty. The 
operations work as follows. 

• INTERNAL- CREATEfT) 
Postcondition: 

create - rcqucstcd(s) = create- rcqucstcd(s') U {T} 

• INFORM -COMMIT- A T(X)OF(T) 
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Postcondition: 

if'l'€ lock- holders') then lock- holdcrs(s) = (lock-holdcrs(s')- { T})U {parcnt(T)} 

• INFORM -ABORT-AT(X)OF(T) 
Postcondition: 

lock - holdcrs(s) = lock - holders') - dcsccndants(T) 

• CRKATK(T) 
Precondition: 

I € create- rcqucstcd(s') - crcatcd(s') 

lock - holders') C anccstors(T) 

Postcondition: 

lock - holders) = lock - holders^') U {T} 

crcatcd(s) = crcatcd(s') U {'I'} 

Note that resilient object R(X) and the lock manager for X share the INFORM -ABORT and 
INFORM-COMMIT input operations. These compose with the output from the concurrent controller 
defined below. 

Thus, the lock manager only sends a CRKATK(T) operation on to the object in case all the current 
lock -holders arc ancestors of T. When the lock manager learns about the commit of a transaction T for 
which it holds a lock, it releases the lock to I"s parent. When the lock manager learns about the abort of a 
transaction T for which it holds a lock, it simply releases all locks held by that transaction and its descendants. 
Our model provides an exceptionally simple and clear way of describing this important algorithm. 

A key property of lock managers is described by the following lemma. 

I^mma 44: Ix:t X be an object and let T and I" be accesses to X. Let U be an ancestor of T 
which is not an ancestor of T. Let o be a schedule of the lock manager for X. If CRKA1 E(T) 
precedes CRKATK(T') in a, then between the two CRKATK operations, there is cither an 
INFORM -COMMIT- A'l'(X)OF(U) operation, or else an INFORM- ABORT- AT(X) for 
some ancestor of T. 

Proof: At the time the CRFATFX'T) occurs, the lock manager puts T into the set of 
lock -holders. Before the lock manager can send in CRFATHO"), it must be that all the 
transactions in lock -holders arc ancestors of T. There are only two ways in which this can 
happen. One possibility is that the lock manager first receives INFORM -COMMITS for all 
ancestors of T up to lca(T,T), including INFORM -COMMIT- AT(X)OF(U). The other 
possibility is that the lock manager first receives an INFORM - ABORT for an ancestor of T. I 

5.2. The Concurrent Controller 

The concurrent controller is similar to the serial scheduler, but it allows siblings to proceed concurrently. In 
order to manage this properly, it interacts with "concurrent objects" (lock managers and resilient objects) 
instead of just basic objects. The operations arc as follows. 
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Input Operations: 

Kl OLUSI -CKHAIIXT) 

RFQUFST-COMMIT(T,v) 

Output Operations: 

CRFATK(T), T a non-access transaction 

I Nil -k N A I .- Cl< KATI^T), T an access transaction 

COM Ml 1(1, v) 

ABORi(T) 

INKORM -COMMIT- AT(X)OF(T) 

INFORM- ABORT- AT(X)OF(T) 

Fach state s of the concurrent controller consists of five sets: create- rcqucstcd(s), crcatcd(s), 
commit- rcqucstcd(s), committcd(s), and abortcd(s). The set commit- rcqucstcd(s) is a set of 
(transaction, value) pairs, and the others arc sets of transactions. (As before, we will occasionally write T € 
commit- rcqucstcd(s) for (T,v) € commit- rcqucstcd(s) for some v.) All sets arc initially empty except for 
create- requested, which is {T fl }. Define rcturncd(s) = committcd(s) U abortcd(s). The operations arc as 
follows. 

• RKQUKST-CRKATKfD 
Postcondition: 

create - rcqucstcd(s) = create- rcqucstcd(s') U {T} 

• RFQUFST-COMMIT(T,v) 
Postcondition: 

commit- rcqucstcd(s) = commit- rcqucstcd(s') U {(T,v)} 

• CRF.A TF(T), T a non-access transaction 
Precondition: 

T € create- rcqucstcd(s') - creatcd(s') 

Postcondition: 

crcatcd(s) = crcatcd(s') U {T} 

• INTERNAL- CREATF(T), T an access transaction 
Precondition: 

T € create— rcqucstcd(s') - crcated(s') 

Postcondition: 

creatcd(s) = crcated(s') U {T} 

• COMMIT(T,v) 
Precondition: 

(l',v) € commit— rcquestcd(s') 

T € rcturncd(s') 

childrcnCO D create - rcqucstcd(s') C rcturncd(s') 

Postcondition: 

committcd(s) = committcd(s') U {T} 
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• ABORT(T) 
Precondition: 

T € (crcatc-rcqucstcd(s') - crcatcd(s*)) U (commit- rcqucstcd(s') - rcturncd(s')) 

childrcn('l') H create- rcqucstcd(s') C rctumcd(s') 

Postcondition: 

creatcd(s) = creatcd(s') U \'V) 

abortcd(s) = abortcd(s') U \'\'} 

• INFORM -COMMIT- AT(X)OF(T): 
Precondition: 

T € committcd(s') 

• INFORM- ABORT- AT(X)OF(T): 
Precondition: 

T € abortcd(s') 

The concurrent controller is closely related to the serial scheduler. In place of the serial scheduler's 
CRKATK operations, the concurrent controller has two kinds of operations, CRKATF. operations and 
1NTKRNAL-CRFATK operations. The former is used for interaction with non-access transactions, while 
the latter is used for interaction with access transactions. From the concurrent controller's viewpoint, the two 
operations arc the same; however, our naming convention for operations requires us to assign them different 
names, since the INTKRNAF-CRFATF operations arc intended to be identified with 
1NTKRNAL-CREATK operations of the lock managers (which also have CRKATF operations, for 
interaction with the resilient objects). 'ITic precondition on the serial scheduler's CREATK operation which 
insures serial processing of sibling transactions, docs not appear in the concurrent controller. Thus, the 
concurrent controller may run any number of sibling transactions concurrently, provided their parent has 
requested their creation. 

The concurrent controller's COMMIT operation is the same as the serial scheduler's COMMIT operation 
(except for a minor difference in bookkeeping). The concurrent controller's ABORT operation is different, 
however: in addition to aborting a transaction in the way that the serial scheduler docs, the concurrent 
controller has the additional capability to abort a transaction that has actually been created and has carried out 
some steps. In this particular formulation, aborts occur if the transaction was not created (as with the serial 
scheduler), or if the transaction has previously requested to commit, and its children have returned. Together 
with the requirements on the COMMIT operation, this condition insures that all transaction completion 
occurs bottom-up. In the weak concurrent system to be considered in Section 6, a different, "weak", 
concurrent controller will be used; it differs from the concurrent controller of this section precisely in not 
requiring ABORT operations to wait for their transactions (and subtransactions) to complete. 

The concurrent controller also has two additional operations not present in the serial scheduler. These 
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operations ;illow the concurrent controller to forward necessary abort and commit information to the lock 
managers and resilient objects. 

Lemma 45: Let a be a schedule of the concurrent scheduler, and let s be a state which can result 
from applying a to the initial state. Then the following conditions arc (rue. 

l.T is in create- rcqucstcd(s) exactly if T = T Q or a contains a RKQUKST— CRKA TK(T) 
operation. 

2. If T is a non-access transaction, then T is in crcatcd(s) exactly if a contains cither a 
CRKATK(T) or AliORT(T) operation. 

3. If T is an access transaction, then T is in crcatcd(s) exactly if a contains cither an 
IN TKRNAL-CRKATH( I ) or AHORTfD operation. 

4. ( T,v) is in commit— rcqucstcd(s) exactly if a contains a COMMIT- RF.QUKST(T,v) 
operation. 

5. (T,v) is in committcd(s) exactly if a contains a COMMIT( T,v) operation. 

6. T is in abortcd(s) exactly if a contains an AHORT(T) operation. 

53. Concurrent Systems 

The composition of transactions, resilient objects and the concurrent scheduler (lock managers and 
concurrent controller) is the concurrent system. A schedule of the concurrent system is a concurrent schedule, 
and the operations of a concurrent system arc concurrent operations. 

A sequence a of concurrent operations is well-formed if for every primitive P, a|P is well-formed (using the 
appropriate definition of well-formedness). 

I he main result of this paper is that every concurrent schedule is serially correct. This will be proved as a 
corollary of a stronger result, in Section 7. 

5.4. Properties of Concurrent Systems 

As we did for serial schedules, we now prove some useful basic properties for concurrent schedules. These 

lemmas describe the possible kinds and orders of operations that can occur in well-formed concurrent 

schedules, l^atcr, we will sec that all concurrent schedules are well-formed, so these properties actually follow 

just from the fact that these schedules arc concurrent All results and proofs in this subsection are 

straightforward. 

IiCmma 46: Let a be a well-formed concurrent schedule, and let T * T_ be a transaction. 

1. If a contains any operation with transaction T, then a contains a CREATE(T) and a 
Rh;QUKST-CRKATK(T). 
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2. If a contains a COMMIT for T. then a contains a RKQUl-XI '-COMMIT for T, a 
CRKATK(T) and a RKQUKSI -CRKA 1 TX T). 

3. If a contains an ABOR T( T), then « contains a KHQUKS T-CRKA THXT). 

Lemma 47: I .ct a be a well-formed concurrent schedule, and I a transaction. Assume that some 
descendant of T is in transaction(a). Then the following hold. 

l.CRKATK(T)occursma. 

2. If T * 1 , then RHQUKS T-CRKATK( I ) occurs in a. 
Lemma 48: I xt a be a well-formed concurrent schedule, and let T * T fl be a transaction. 

1. If a contains a RKQUKST-CRKATK(T), but docs not contain a return operation for T, 
then parcnt(T) is live in or. 

2. If T is live in a, then parcnt(T) is live in a. 

3. If o contains a RKQUKST-CRKATKfO but docs not contain a CRKATK(T) or 
ABORT(T), then parcnt( T) is live in a. 

Proof: 1. Well-formedness implies that the RlvQUKST-CRKATK(T) is preceded by a 
CRHAThXparcntCI')). Suppose tliat parcnt( T) is not live in a. Then a return operation for 
parcnt(T) occurs in a. In case the return operation for parcnt(T) is an ABORT(parcnt(T)), 
scheduler preconditions imply that the CRKATK(parcnt(T)) must precede the 
AliORT(parcnt(T)). llicn the scheduler preconditions for the return operation imply that the 
return for parcnt(T) must be preceded by a RKQUKST-COMMIT for parcnt(T). By well- 
formedness, the RKQUHST-COMMIT for parcnt(T) must follow the RKQUKST-CRKATFXT), 
so that the return for parcnt( T) must follow the RHQUHST-CRHA TH(T) Then the scheduler 
preconditions for the return operation imply that there must be a return operation for T in a, a 
contradiction. 

2. and 3. arc as in Lemma 17. I 

lA'mma 49: Let o be a well-formed concurrent schedule, and IctT be a transaction. 

1. If a contains a RHQUKST-CRKATFX'O, but does not contain a return operation for T, 
then all proper ancestors of T arc live in a. 

2. If T is live in a, then any ancestor of T is live in a. 

3. If a contains a RKQUKST-CRKATHf but docs not contain a CRRATEfT) or 
AIK)RT(T), then all proper ancestors of T arc live in a. 

Lemma 50: Let o be a well-formed concurrent schedule, and let T and T be transactions with T 
a descendant of T. Assume that there is a return operation for T in a. 

1. If there is a RKQUKST-CRKA TR(T) in a, then there is a return operation for T in a. 

2. If T is in transaction(a), then there is a return operation forT" in a. 
Proof: 
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1. By Lemma 49. 

2. By I .emma 46 and part 1. 
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Lemma 51: Let « be a well-formed concurrent schedule. Ifa return operation fori' is in a, then 
it follows all operations in a whose transaction is T. 

Proof: hirst consider the case where T is not an access. If no CRKATK(T) occurs in a, the result 
is immediate, so assume that CRKAITXT) occurs in a. In case an ABORT(T) occurs in a, 
scheduler preconditions imply that the CRKATK(T) must precede the ABOR T(T). Then the 
return operation for T must be preceded by a RKQU LSI -COMMIT for T. by scheduler 
preconditions. Well-formedness implies that the RKQUKST-COMMIT is preceded by 
CRKATKTT). <>nd is not followed by any output operations of T. Ilius, the only serial operations 
of T that could follow the RKQUKST-COMMIT arc return operations of children of T. 

Let T be a child of T for which a return operation occurs in a. By scheduler preconditions, 
there is only one return operation for T in a. By Lemma 46, a also contains 
RKQUKST-CRKATKCO. Since this is an output operation of T, it precedes the 
RKQUKST-COMMIT fori', and hence precedes the return operation forT. 'Ilicn the scheduler 
preconditions imply that the return operation for T precedes the return forT. 

Next, consider the case where T is an access. If no INTKRNAL-CRKA TK( T) occurs in a, the 
result is immediate, so assume that INTKRNAL-CRKA TK(T) occurs in a. In case an 
ABORT( T) occurs in o, scheduler preconditions imply that the I NTKRNAL- CRKATKTT) must 
precede the ABORT(T). Then the return operation for T must be preceded by a 
RKQUKST-COMMIT for T. and well-formedness implies that this is in turn preceded by 
CRKAThX'T). 'Thus, no serial operations of T can follow the return operation forT. I 

Umma 52: Let a be a well-formed concurrent schedule. Ifa return operation forT is in a, then 
it follows all operations in o whose transactions arc descendants of T. 

Proof: Since a return operation for T occurs in a, we have T * T Q . Let T be a descendant of T, 
and assume for the sake of obtaining a contradiction that a serial operation w with transaction it) 
= T occurs after the return for T in a. Let a be the prefix of a preceding ir. 

By Lemma 46, a contains a RHQUKST-CREATEfr). Then Lemma 50 implies that a must 
contain a return operation for T. But then the well-formed schedule av contains a return 
operation for T followed by an operation of T, which contradicts Lemma 51. I 

Weak concurrent systems arc defined in the following section, and many of their properties arc stated and 
proved. Weak concurrent systems arc obtained by replacing the concurrent scheduler with a more permissive 
scheduler, the weak concurrent scheduler. Results in Section 7 prove that every execution of the concurrent 
system is also an execution of the weak concurrent system. Thus, additional interesting properties of 
concurrent system behavior follow immediately from the corresponding properties of weak concurrent system 
behavior, proven in that section. 
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6. Weak Concurrent Systems 

In this section, wc define "weak concurrent systems", which arc exactly the same as concurrent systems, 
except that they have a more permissive controller, the "weak concurrent controller". The weak concurrent 
controller reports aborts to a transaction's parent while there is still activity going on in the aborted 
transaction's subtree. In this paper, weak concurrent systems arc used primarily to provide an intermediate 
step in proving the correctness of concurrent systems: proving a weaker condition for weak concurrent 
systems allows us to infer the stronger correctness condition for concurrent systems. However, weak 
concurrent systems arc also of interest in themselves. In a distributed implementation of a nested transaction 
system, performance considerations may make it important for the system to allow a transaction to abort 
without waiting for activity in the transaction's subtree to subside. In this case, a weak concurrent system 
might be an appropriate choice, even though the correctness conditions which they satisfy arc weaker. Weak 
concurrent systems also appears to have further technical use, for example in providing simple explanations of 
the ideas used in "orphan detection" algorithms [HI.MWJ. 

6.1. The Weak Concurrent Controller 

In this subsection, wc define the weak concurrent controller. As wc have already said, it is identical to the 
concurrent controller except that it has a more permissive ABORT operation. For convenience, wc describe 
the controller here in its entirety. It has the same operations as the concurrent controller: 

Input Operations: 

RKQUFST-CRFATFXT) 
R KQU KST - COM M IT(T,v) 

Output Operations: 

CRKA TF(T), T a non-access transaction 

1NTFRNAL-CRFATFXT), T an access transaction 

COMMIT(T.v) 

ABORT(T) 

INFORM -COMMIT- AT(X)OF(T) 

INFORM -ABORT- A T(X)OF(T) 

Each state s of the concurrent controller consists of five sets: create- requcstcd(s), crcatcd(s), 
commit- rcqucstcd(s), committcd(s), and abortcd(s). The set commit- rcqucstcd(s) is a set of 
(transaction, value) pairs, and the others are sets of transactions. (As before, wc will occasionally write T € 
commit- rcqucstcd(s) for (T,v) € commit- rcqucstcd(s) for some v.) All are empty initially except for 
create -requested, which is {T }. Define rcturncd(s) = committcd(s) U abortcd(s). The operations arc as 
follows. 

• REQUKST-CREATECD 

Postcondition: 
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create- rcqucslcd(s) = create- requested^') U {'I'} 

• RHQUHST-COMMIT(T,v) 
Postcondition: 

commit- rcqucstcd(s) = commit- rcqucstcd(s') U {(T.v)} 

• CKIvA'I'FX'l"), I a non-access transaction 
Precondition: 

T € create- rcqucstcd(s') - crcatcd(s') 

Postcondition: 

crcatcd(s) = crcatcd(s') U {'I'} 

• INTKRNAI.-CRKATK(T), I' an access transaction 
Precondition: 

T € create — requcstcd(s') - crcatcd(s') 

Postcondition: 

crcatcd(s) = crcatcd(s') U {'I'} 

• COMMIT(T.v) 
Precondition: 

(T,v) € commit- rcqucstcd(s') 

T € rcturncd(s') 

childrcn(T) H create - rcqucstcd(s') C rcturncd(s') 

Postcondition: 

committcd(s) = committcd(s') U {T} 

• ABORT(T) 
Precondition: 

T € creatc-rcqucstcd(s') - returncd(s') 

Postcondition: 

crcatcd(s) = crcatcd(s') U {T} 

abortcd(s) = abortcd(s') U {T} 

• INFORM -COMMIT- AT(X)OF(T): 
Precondition: 

T € committcd(s') 

• INFORM- ABORT- AT(X)OF(T): 
Precondition: 

T € aborted(s') 

Thus, the weak concurrent controller is permitted to abort any transaction that has had its creation 

requested, and which has not yet returned. 

Lemma 53: Let a be a schedule of the concurrent scheduler, and let s be a state which can result 
from applying a to the initial state. Then the following conditions are true. 

l.T is in create- rcqucstcd(s) exactly if T = T Q or a contains a RKQUHST-CREATFXT) 
operation. 
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2. If T is a non-access transaction, then T is in crcatcd(s) exactly if a contains cither a 
CRKATK(T) or AliORT(T) operation. 

3. If '[' is an access transaction, then T is in crcatcd(s) exactly if a contains cither an 
IN TERNAI.-CREATK(T) or AUORT(T) operation. 

4. (T.v) is in commit- rcqucstcd(s) exactly if a contains a COMMIT- RHQUEST(T,v) 
operation. 

5. (T.v) is in committcd(s) exactly if a contains a COMMIT( T,v) operation. 

6. T is in abortcd(s) exactly if a contains an AliOR T( T) operation. 

6.2. Weak Concurrent Systems 

The composition of transactions, resilient objects and the weak concurrent scheduler (lock managers and 
weak concurrent controller) is the weak concurrent system. A schedule of the weak concurrent system is a 
weak concurrent schedule. 

Weak concurrent systems exhibit nice behavior to transactions except possibly to those which arc 
descendants of aborted transactions. Thus, wc say that a transaction T is an orphan in any sequence a of 
operations provided that an ancestor of T is aborted in a. In many of the properties wc prove for weak 
concurrent systems, wc will have to specify that the transactions involved arc not orphans. 

6.3. Properties of Weak Concurrent Systems 

As wc did for serial and concurrent schedules, we here prove a number of useful basic properties for weak 
concurrent schedules. As before, most of these properties arc simple to state and prove. 

6.3.1. Operations in Weak Concurrent Schedules 

As before, wc include a collection of lemmas describing the possible kinds and orders of operations that can 

occur in well-formed weak concurrent schedules. These lemmas are analogous to some in Section 5, and have 

similar proofs; the main difference is that wc must take proper care with orphans. As before, we go on to 

show that all weak concurrent schedules arc well-formed, so these properties actually follow just from the fact 

that these schedules arc weak concurrent. 

lamina 54: Let a be a well-formed weak concurrent schedule, and let T * T be a transaction. 

1. If a contains any operation with transaction T, then a contains a CREATE(T), and a 
RKQUKST- CRKATbXT). 

2. If a contains a COMMIT for T, then o contains a REQUEST- COMMIT for T, a 
CREAThXT) and a RKQUES T-CRKA TE( T). 

3. If a contains an ABOR T(T), then a contains a REQUKST-CREA TE(T). 
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Lemma 55: I ,ct a be a well-formed wc;ik concurrent schedule, and T a transaction. Assume that 
some descendant of T is in transaction^ ). Then the following hold. 

l.CRKA'I'hX'l') occurs in o. 

2. IfT * T , then Rl-QUKS'I '-CRKATKO') occurs in a. 
Iimniu 56: Let a be a well-formed weak concurrent schedule, and let T * T Q . 

1. If a contains a RKQUEST-CREATIXT), but docs not contain a return operation for T, 
then parcnt(T) is not committed in a. 

2. IfT is live in a, then parcnt(T) is not committed in a. 

3. If a contains a RHQUKST-CRKA 11X1) but docs not contain a CRKATK(T) or 
ABOR T( T), then parcnt( T) is not committed in a. 

Proof: 1. Suppose a COM MIT operation for parcnt( T) occurs in a. Then the weak concurrent 
controller preconditions for the COM Mil' operation imply that the COM MIT for parcnt(T) must 
be preceded by a REQUEST-COMMIT for parcntfT). By well-formedness, the 
REQUEST- COM MIT for parcnt(T) must follow the REQUEST-CREATEO), so that the 
COMMIT for parcnt( T) must follow the REQUEST-CREATI-XT). ITicn the weak concurrent 
controller preconditions for the COMMIT operation imply that there must be a COMMIT 
operation for T in a, a contradiction. 

2. and 3. arc as in 3.6.2. I 

Lemma 57: Let a be a well-formed weak concurrent schedule, and let T be a transaction which 
is not an orphan in a. 

1. If a contains a REQUEST- CREATEfT), but docs not contain a COMMIT operation for 
T, then all proper ancestors of T arc live in a. 

2. IfT is live in a, then all proper ancestors of T arc live in a. 

3. If a contains a RKQUKST-CRKATK(T) but docs not contain a CREATK(T), then all 
proper ancestors of T arc live in a. 

Proof: By repeated use of the previous lemma, well-formedness and the weak concurrent 
controller preconditions. I 

Lemma 58: Let a be a well-formed weak concurrent schedule, and let T and T be transactions 
with T a descendant of T. Assume that T is not an orphan in a and that there is a COMMIT 
operation for T in o. 

1. If there is a REQUEST- CRKATE('r) in a, then there is a COMMIT operation for T in 
a. 

2. If T is in transaction a), then there is a COMMIT operation for T in a. 
Proof: 

1. By I .emma 57. 
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2. By Lemma 54 and part 1. 
I 

6.3.2. Objects and lacking 

In this paragraph, wc give two simple lemmas about the behavior of the locking strategy. 

liVmma 59: Let a be a weak concurrent schedule. Let X be an object, and let T and T be 
accesses to X. Let U be an ancestor of T which is not an ancestor of T. Assume that CRKA 1 K( T) 
precedes CRLA TK( T) in a. 

l.'ITicrc is cither an INFORM-COMMIT- AT(X)OF(U), or else an 
INFORM -ABORT- AT(X) for some ancestor of T, occurring between CRFATK(T) and 
CRKA'I'hX'Dina. 

2. Kithcr CRFA'THO") is preceded by a COMMIT operation for U, and by a 
RKQUKS T-COMMIT operation for U, or else CRKATHfl") is preceded by an ABORT 
operation for some ancestor of T. 

Proof: 

1. By Lemma 44. 

2. By part 1 and the preconditions of the weak concurrent controller. 

I 

Ixmma 60: Let a be a well-formed weak concurrent schedule, and X a basic object, 'linen the 
set of active transactions after a|R(X) is exactly the set of lockholdcrs in the lock manager for X 
after a. 

Proof: By induction on the length of a. I 

6.3 J. Well-Formedness 

Here, wc show that every weak concurrent schedule is well-formed. It follows that all the properties proved 

earlier in this section arc actually true for all weak concurrent schedules. From now on, wc will use these 

properties without explicitly mentioning well-formedness. 

Ixmma 61: Ixt a be a weak concurrent schedule. 'Then a is well-formed. 

Proof: By induction on the length of schedules. The base, length = 0, is trivial. Suppose that 
air is a weak concurrent schedule, where m is a single operation, and assume that a is well- 
formed. If tt is an output of a primitive P, then the result is immediate, since each primitive 
preserves well-formedness. No INTKRNAL-CRKATK operation can cause a violation. So 
assume that m is an input to a primitive P. It suffices to show that aw|P is well-formed. 'There are 
six cases. 

(1) w is CRKATF-CD and T is a non-access transaction. 

ITic controller preconditions insure that CREA'TFX'T) does not appear in a. 

(2) it is CRFATF-OT) and 'I' is an access to resilient object R(X). 

By the lock manager preconditions, no CRKATR(T) appears in a. 'ITic lock manager 
preconditions and Lemma 60 imply that all the transactions which are active after a are ancestors 
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of T. 

(3)w isCOMMIT(T,v). 
Then m is an input to transaction parcnt( I). Weak concurrent controller preconditions imply that 
a contains RFQUFST-COMMIT(T.v), and so Lemma 54 implies that o contains 
RFQUFST-CRFAITX T). Also, weak concurrent controller preconditions insure that a docs not 
contain a return operation f'orT. 

(4)*isAllOKT(T). 

Then m is an input to transaction parcnl(T). Weak concurrent controller preconditions imply that 
a contains a RFQUFS T-CRFA I K( T). Weak concurrent controller preconditions insure that a 
docs not contain a return operation for T. 

(5) wis INFORM -COMMIT- AT(X)OF(T) at resilient object R(X). 
By the preconditions of the weak controller, a contains a COMMIT for T. If 
INFORM- ABORT- AT(X)OF(T) occurs in a, then a also contains an ABORT for T, which 
contradicts weak concurrent controller preconditions. 'ITius, no 

INFORM- ABORT- AT(X)OF(T) occurs in a. Since a COMMIT for T occurs in a, weak 
concurrent controller preconditions imply that a RFQUFS T-COMMN for T also occurs in a. 

(6)tt is INFORM- ABORT- AT(X)OF(T) at resilient object R(X). 
By the preconditions of the weak concurrent controller, a contains ABORT(T). If 
INFORM -COMMIT- AT(X)OF(T) occurs in a, then a contains a COMMIT for T, which 
contradicts weak concurrent controller preconditions. 'Thus, no 

INFORM -COMMIT- AT(X)OF(T) occurs in a. I 

63.4. Visibility and Weak Concurrent Schedules 

ITiis paragraph states and proves important properties involving visibility in weak concurrent schedules. In 
particular, the most important result of this paragraph is Lemma 66, which relates the portion of a weak 
concurrent schedule which is visible to a particular transaction, to schedules of transactions and basic objects. 
The first lemma shows how visibility propagates among the transactions during a weak concurrent execution. 
Lemma 62: Let am be a weak concurrent schedule, where it is a single operation. 

1. If m isCREATFTT), then visiblc(aff.T) = visiblc<a,parcnt(T))w- 

2. If m isCOMMTT(T.v), then visiblc(a7r,parcnt(T)) = visiblc(a,T)tr. 

3. If it is ABORT(T), then visiblc(aw,parcnt(T)) = visiblc(a,parcnt(T))w. 

4. If it is COMMIT(T,v), and V is a descendant of parcntfT) but not T, then visiblc(oir.T) - 
visiblc(aw,parcnt(T)) = visiblc(ot, T) - visiblc(a,T). 

Proof: 1. By Lemma 55, w is the first serial operation in am whose transaction is a descendant of 
T, and T is not visible to parcnt(T). Thus any transaction other than T visible to T in ow is visible 
to parcnt(T) in am. Then parcnt(T) is visible to T in am, and by Lemma 8, 
visiblc(att.parcnt(T))w = visiblciaw.T). 
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By the definition of visibility, any transaction visible to parcnt( I ) in am is visible to parcnt(T) in 
a, and visiblc(ot.parcnt(T)) = visiblc(aw,parcnt(T)). Substituting in the equality above, we have 
the result. 

2. By the definition of visibility, any transaction visible to parcntfl') in am is cither visible to 
parcnl(T) in a, or is visible to T in a. I kit any transaction visible to parcnt(T) in a is visible to T in 
a, so wc have that any transaction visible to parcntCI) in am is visible to T in a, and 
visiblc(aw,parent(T)) is a subsequence of visiblc(a,T)w. It follows immediately from the 
definition of visibility that any transaction visible to T in a is visible to parcntCI) in am, so that 
visible(a.T) is a subsequence of visiblc(o7r.parcnl('l'). The result is immediate. 

3. Immediate from the definition of visibility. 

4. Clearly, visiblc(a,T) is a subsequence of visiblcfaw.T). Any operation in visiblc(aw,T) - 
visiblc(a, T) has a transaction which is a descendant of T, and so is cither w or is visible to T in a, 
and thus is in visiblc(a,T)7r. Thus wc have visiblc(a7j\T) - visiblc(a,T)w = visiblc(a,T) - 
visible(a,T)7r. As m is not in visiblc(a,T), this equals visible(a,T) - visiblc(a,T). liy part 2, 
visiblc(aw,parcnt(T)) = visiblc{a, \')m, and tlic result follows by substitution in the first identity. 



Now wc prove two lemmas involving visibility and the behavior of resilient objects in weak concurrent 
systems. 

lyvmma 63: I .ct a be a weak concurrent schedule. Ixt R(X) be a resilient object, and let T and T 
be accesses to R(X). If T is live and not an orphan in a and CRHATK( I ') occurs in a, then cither 
T is visible to T in a, or else CRKATFXT) is in the scope of an 
INFORM - ABORT- AT(X)OF(U) in a|R(X). 

Proof: ITicrc arc two cases. 

(1) CRKATFXD precedes CRKATKf D in a. 

Assume T is not visible to T in a. Then Lemma 59 implies that there is an 
INFORM — ABORT— AT(X) operation for some ancestor of T, occurring after CRHATFTl") in a. 

(2) CRFATFCT) precedes CRKATKf I') in a 

Then Lemma 59 implies that there is cither a COMMIT or an ABORT for some ancestor of T, in 
a. Since T is not an orphan in a, there is a COMMIT for an ancestor of T in a. Then Lemma 58 
implies that T is returned in a, a contradiction. I 

Ivcmma 64: Let a be a weak concurrent schedule. Let R(X) be a resilient object, let T and T be 
accesses to R(X), and let T' be any transaction. Assume that T is not an orphan in a. If an 
operation m of T precedes an operation m' of T in a, v is not in the scope of an 
INFORM -ABORT and T is visible to T' in a, then T is visible to T" in a. 

Proof: By well-formedness, CRKATEfT) and CRF.ATF(T) arc operations in a, in that order. 
Let a' be the prefix of a ending with CRKATFXT). ITicn T is live and not an orphan in a. By 
Lemma 63, T is visible to T in a\ and so in a. Lemma 8 implies that T is visible to T" in a. I 

'Hie following lemma is straightforward. 

Lemma 65: Let a be a weak concurrent schedule, and let T be a transaction which is not an 
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orphan in a. Any transaction 'I" visible to T in a is not an orphan in a. 

Proof: If T" is an ancestor of T, the result is immediate. Otherwise, COMMIT operations appear 
in a for every proper descendant of lca(T.T) that is an ancestor of'l". Hy well-formedness, none 
of these transactions has aborted. Since the remaining ancestors of'l" arc also ancestors of T, and 
the result follows. I 

We arc now ready to prove the key lemma of this paragraph. 

U'liima 66: Let a be a weak concurrent schedule, let T be live and not an orphan in a, and let F 
be a resilient primitive. 

1. If P is a transaction 1", then visiblc(a,T)|T is a prefix of a\ T and a schedule of T. 

2. If P is a resilient object R(X), then visiblc(a,T)|R(X) is a prefix of undo(a|R(X)) and a 
schedule of basic object X. 

Proof: 1. Immediate from Lemmas 11 and 1. 

2. First, we show that any operation in visiblc(a, T)|R(X) also occurs in undo(a|R(X)). If v is in 
visiblc(a,T)|R(X), it means that all ancestors of transaction^ ) up to lca(transaction(w),T) have 
committed. Hy assumption, T is not an orphan in a, so Lemma 65 implies that transaction^ ) is 
not an orphan in a. Thus, by the preconditions of the weak concurrent controller there is no 
INFORM -ABORT for any ancestor of transaction w) in a. Therefore, it is in undo(a|R(X)). 

Now we consider any two operations it and it' of undo(a|R(X)), where it precedes it\ Assume 
that it' is in visible(a,T)|R(X). Let T" = transaction w) and T = transaction(ir'). Then T is 
visible to T in a, and T is not an orphan in a by Lemma 65. Since it is in undo(a|R(X)), no 
INFORM -ABORT occurs at R(X) for any ancestor of T" in a, with it in its scope. Then Ixmma 
64 implies that V is visible to T in a. Thus, v is in visiblc(a,T)|R(X). It follows that 
visiblc(a,T)|R(X) is a prefix of undo(o|R(X)). 

By Lemma 61, a|R(X) is a well-formed schedule of resilient object R(X). Then the resiliency 
condition implies that undo(a|R(X)) is a schedule of basic object X. So by Lemma 1, 
visiblc(a,T)|R(X) is a schedule of basic object X. I 

Finally, we prove that, in a weak concurrent schedule, concurrently executing transactions access disjoint 

sets of resilient objects. 

Lemma 67: Let a be a weak concurrent schedule, with transactions T and T live and not 
orphans in a. IxtT = lca(T,T). Lct0 = visiblc(a,T) - visiblc(a,T") and ? = visibleia/T) - 
visiblc(a,T"). 'lhcn no resilient object has operations in both fi and /T. 

Proof: The result is trivial if T is an ancestor of T or vice versa. So assume that lca(T.T) is 
neither T nor T. Let R(X) be a resilient object such that both fi and /T contain operations of 
R(X). By well-formedness, we can assume without loss of generality that there are two accesses to 
X (not necessarily distinct) such that it = CRKA TK(U) and <p = CRKATE(V) arc in and p\ 
respectively, and neither U nor V is visible to IcafT.T) in a. Also, we can assume that it appears 
in a no later than <p. 

We have that U is visible to some ancestor of T in a, and V is visible to some ancestor of T in a, 
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and since T and T arc not orphans in a. I .cm ma 65 implies that no ancestor of U or V has aborted 
in a. Also, neither U nor V is visible to lca(T. I ") in a, so it must be that U * V. But then it 
precedes <p in a. and Lemma 59 implies Unit some ancestor of T is committed in a. 'Ihcn Lemma 
57 implies that T is returned in a, a contradiction. I 

7. Simulation of Serial Systems by Concurrent Systems 

In this section, we prove the main rcsuks of this paper, that concurrent schedules arc serially correct, and 
that weak concurrent schedules arc correct at I Q . Both these results follow from an interesting theorem about 
weak concurrent schedules, which says that the portion of any weak concurrent schedule which is visible to a 
live non-orphan transaction is equivalent to (i.e. looks the same at all primitives as) a serial schedule. 

The proof of this theorem is quite interesting, as it provides considerable insight into the scheduling 
algorithm. The proof shows not only that a transaction's view of a weak concurrent schedule is equivalent to 
some serial schedule, but by a recursive construction, it actually produces such a schedule. It is interesting and 
instructive to observe how the views that different transactions have of the system execution get passed up 
and down the transaction tree, as CRKATKS, COMMITS and ABORTS occur. 

Theorem 68: Let a be a weak concurrent schedule, and T any transaction which is live and not 
an orphan in a. 'Ihcn there is a serial schedule /? which is equivalent to visiblc(a,T). 

Proof: We proceed by induction on the length of a. The basis, length 0. is trivial. Fix a of 
length at least 1, and assume that the claim is true for all shorter weak concurrent schedules. Ixt it 
be the last operation of a, and let a = am. Fix T which is live and not an orphan in a. We must 
show that there is a serial schedule fi which is equivalent to visiblc(a,'T). 

If w is not a serial operation, then visiblc(aM') = visiblc(scrial(a'),T) = visiblc(scrial(a),T) = 
visiblc(a,T), and the result is immediate by induction. So wc can assume that v is a serial 
operation. Also, if transaction w) is not visible to T in a, then visiblc(a,T) = visiblc(a',T), and 
the result is again immediate by induction. 'Thus, wc can assume that transaction(w) is visible to T 
in a. Also, T is not an orphan in o'. 

There arc four cases. 

(1) m is an output operation of a transaction or resilient object. 

Then the inductive hypothesis implies the existence of a serial schedule /?' which is equivalent to 
visiblc(aVT). Lct/3 = /3'w. Wc must show that /? is equivalent to visiblc(a,T) and serial. 

Let P be any primitive. Then y8|P = 0V|P = visiblc(a',T)7r|P by inductive hypothesis, = 
visiblc(a,T)|P, by Lemma 12. Therefore, /J is equivalent to visiblc(a,T). 

Let m be an output of primitive P. Then >8|P = visiblc(a,T)|P by equivalence, which is a 
schedule of P by Lemma 66. Lemma 4 implies that /3 is serial. 

(2) m is a CRKATK( T) operation. 

Then transaction tt) = T, and so T is visible to T in a. Ihcn Lemma 55 implies that w is the first 
operation whose transaction is a descendant of 1". Ihcn by the definition of visibility, it must be 
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thatT = T. My Lemma 57, parcnt( T) is live in a'. Since parcnt(T) is not an orphan, the inductive 
hypothesis implies the existence of a serial schedule ft' which is equivalent to visible(a'.parcnt(T)). 
Let/? = P'v. We must show that /? is equivalent to visiblc(a,T) and serial. 

Let P beany primitive. Then /3|P = P'n\\\ = visible(o',parcnt( T))w|Pby inductive hypothesis, 
= visiblc(a.T)|P. by l.cmma 62. Thus, /8 is equivalent to visiblc(a.T). 

Consider any execution of the serial system having /?' as its operation sequence, and let s' be the 
state of the serial scheduler after /?'. We show that ir is enabled in s". That is, we show that T € 
create -requcstcd(s'), thatT € crcatcd(s'). and that siblings(T) PI crcatcd(s') C rcturncd(s'). 

Consider any execution of the weak concurrent system having a as its operation sequence, and 
lets be the suite of the weak concurrent scheduler after a'. State s contains a component s c for the 
weak concurrent controller and a component s x for the lock manager for each object X. 

If T = 'I' then T € create- rcquestcd(s') by the initial conditions. If T * T , then T € 
create- rcqucstcd(s ) by the preconditions of the concurrent scheduler, so a 
RHQUKST-CRKATLTi') operation occurs in a'. The RKQUKS T-CRRATK(T) operation has 
transaction parcnt(T), and so is in visiblc(a',parcnt( T)), and thus is in fi\ Therefore, T € 
create — rcqucstcd(s'). 

If T € crcatcd(s'), then there is cither a CRHATKfT) or an ABORT(T) operation in /T, and 
hence in a. In the former case, a would have two such operations, while in the latter case, a 
would have an ABORT(T) followed by a CRKATK(T). Hoth arc impossible, so T £ crcated(s'). 

Assume U € siblings(T) D crcatcd(s'). Ihcn there is cither a CRLAI K(U) or an ABORT(U) 
operation in /T. In the latter case, U is obviously in rcturncd(s'). So suppose CRKATK(U) occurs 
in fi\ and so in visiblc(a',parcnl(T)). Since CRHA TH(U) cx;curs at U, U is visible to parcnt(T) = 
parcnt(U) in a; thus, COMMIT(U,u) occurs in a\ for some u. Since COMMIT(U.u) occurs at 
parcnt(T), COM Ml T(U,u) is in visiblc(a',parcnt( T)), and so in j8\ Thus, U € rctumcd(s'). 

(3) n is a COMM IT(T\v) operation. 
Then T" = parcnt( I") = transaction(7r) is visible to ']' and not an orphan in a. Also, T is not an 
orphan in a\ by Lemma 65. 'llicn since a is well-formed, T is live in a\ and so by Lemma 57, T" 
is live in a and so in a. Since T" is live and visible to T, T" is an ancestor of T. Since T is live in 
a. Lemma 58 implies that T is not a descendant of I ". Ihc inductive hypothesis yields two serial 
schedules, /?' and /T, which arc equivalent to visiblc(aVO and visiblc(a'.T), respectively. Let y 
= visiblcl/S'T'). Let fi 1 = j8' - y and /8 2 = ^3" - y. We show that fi = yfi 1 irP 2 is cc l uivalent to 
visible(a,T) and serial. 

Lemma 28 implies that y is a serial schedule. 

Since T" is visible to T in a'. Lemma 10 implies that visiblc(a',T") = visiblc(visible(a\T),T"), 
which is equivalent to visiblc(/S',T") = -y; thus y is equivalent to visiblc(a\T"). Also, since T" is 
visible to T in a', Lemma 10 implies that visiblc(a\T') = visiblc(visiblc(a',T),r'), which is 
equivalent to visible(/r\ T"). Thus, y is also equivalent to visiblc(/?",T')- 

'ITien by Lemma 31 (applied with scrial(a') as the schedule « hypothesized in the lemma), yfi x 
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and y/?, arc serial schedules which arc equivalent to /T and /?'", respectively. 

We have that visihlc(a,T") = visiblc(a\ 1")ti by I .emma 62, which is equivalent to fi'it, which is 
in turn equivalent to y/i,7r. That is, visiblc(a.T') is equivalent to y^w. 

Since /?" is equivalent to visiblc(a'.T) and y is equivalent to visiblc(a\T"). by I .emma 10, /? 2 — 
/?" - y is equivalent to visiblc(aM') - visible(a',T"), = visiblc(a.'l') - visiblc(a,T") by I .emma 62. 

Thus, fi is equivalent to visiblc(«, T"Xvisiblc(a. T)-(visiblc(o, T")). Since 1" is visible to 'I' in a, 
by Lemma 8, it is easy to sec that the same operations appear in this schedule as in visiblc(a,T). 
Let P be any primitive. Then visiblc(a,T"))|P is a prefix of visiblc(a.T)|P, by I. emma 66. It 
follows that /?|P = visiblc(cr,T)|P, so that/? is equivalent to visiblc(a,T). 

It remains to show that /? is serial. This follows from Lemma 32, provided wc can show that: 
(3.a) Y/8j7r is a serial schedule, 
(3.b)T sees everything in yp y 
(3.c) T sees everything in y/L, 
(3.d)y = visibUKy/JpT) = visiblc(y^ 2 ;r') and 
(3.c) no basic object has operations in both /? ( and /5j. 

(3.a) Consider any execution of the serial system having y/?| as its operation sequence, and let s' 
be a state of the serial scheduler after yP y Wc show that -rr is enabled in suite s\ lhan is, wc show 
that (T.v) € commit - rcqucstcd(s'), that 'I" £ returned^'), and that childrcn(T) D 
create -rcqucstcd(s') C rcturncd(s'). 

Consider any execution of the weak concurrent system having a as its operation sequence, and 
let s be the state of the weak concurrent scheduler after a\ with components s c (the weak 
controller state), and s x for every object X (the lock managers). 

Since the weak concurrent scheduler is able to perform COMMIT(T\v) in state s, it must be that 
(T.v) is in commit- rcquestcd(s ), and so it must be that 'I" issues a RKQUKST-COMMlT(T\v) 
in a\ Since T is visible to itself, and /T is equivalent to visiblc(a\T), it follows that this 
RKQUKST-COMMIT('r,v) operation also occurs in yfi r Therefore, (T.v) is in 
comm it - rcqucstcd(s'). 

Since a is well-formed, at most one return operation for T appears in o; thus, T is not in 
rcturncd(s'). 

Fix U € childrcn(T) H create - rcqucstcd(s'). ITicn RFQUKST-CREATK(U) is performed at 
T in yfi v and hence in a, so U € create- rcqucstcd(s c ). Since the weak concurrent scheduler is 
able to perform COMMlT(T,v) in state s, it must be that U € rcturncd(s c ). Therefore, a return 
operation for U is performed at T, in a. Since T is visible to itself, and yp { is equivalent to 
visiblc(a',T), this implies that the return for U also occurs at T in y/?j. Therefore, U is in 
rcturncd(s'). 

(3.b) Immediate from Lemma 10. 

(3.c) Immediate from Lemma 10. 
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(3.d) Wc have that y is equivalent to both visiblc(/?',T") and visible(/T, I"*). and that y>9 , and 
y/L arc equivalent to 0' and fi", respectively. By lemma 10, y is equivalent to both 
visiblc(y/?,,T')and visiblc(y/? 2 .T"). l-xjuality follows. 

(3.c) Immediate from Lemma 67. 

(4) it is an ABOR 1(1") operation. 
Then T" = parcnt(T) = transaction^ ) is visible to T in a, and so is not an orphan in a, by 
Lemma 65. Then T is live in a\ and by Lemma 57, T is live in a and so in a. Since T' is live 
and visible to T in a, T is a descendant ofT". Since T is not an orphan in a. T is not a descendant 
of I". ITic inductive hypothesis yields two serial schedules, /?' and /?", which arc equivalent to 
visiblc(a'.T') and visiblc(a'.T), respectively. Let P l = /T - fi\ Wc show that /? = /Tw/Sj is 
equivalent to visiblc(a,T) and serial. 

By Lemma 31, 07? j is a serial schedule which is equivalent to /T. 

Let P be a primitive other than T". ITicn 0|P = 0*0 ,|P = £"|P = visiblc(aVr)|P, = 
visiblc(a,T)|P by Lemma 62. Also, since T" is visible to T in a, visiblcKa.'OlT" = 
visiblc(a,T")|T", = visiblctaVr'MT' by Lemma 62, = 0'w|T" = fiW"- Thus/3 is equivalent to 
visib1c(a,T). 

It remains to show that /} is serial. Ihis follows from Lemma 33, provided wc can show that: 
(4.a) P'it is a serial schedule. 
(4.b) I' sees everything in fi'fi ,, and 
(4.c)/?' = visiblc(/8Vr') = visiblcOS'^^T"). 

(4.a) Consider any execution of the serial system having /?' as its operation sequence, and let s' 
be a state of the serial scheduler after /?'. Wc show that <n is enabled in state s'. That is, wc show 
that P € create -rcqucstcd(s'), that T € crcatcd(s'), and that siblings(T) D crcatcd(s') C 
rctumcd(s'). 

Consider any execution of the weak concurrent system having a as its operation sequence, and 
let s be the state of the weak concurrent scheduler after a\ with components s (the weak 
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Since the weak concurrent scheduler is able to perform ABORT(T) in state s, it must be that T 
is in create- rcqucstcd(s c ), and so it must be that T" issues a RF,QUEST-CRKAThXT) in a. 
Since T" is visible to itself, and /?' is equivalent to visiblcfaYO, it follows that this 
REQUEST- CRKATKCn operation also occurs in 0'. Therefore, T is in create - requested^'). 

Since o cannot contain two ABORT(T) operations, there cannot be an ABORT(T) operation in 
a\ and so there cannot be one in 0'. Assume that there is a CREATEO") in /?'. 'Ihen T is visible 
to T" in a\ so COMMIT(T') occurs in a. But then a COMMITO") and and ABORTO") both 
occur in a, which cannot occur. Therefore, there is neither an ABOR T(T) nor a CREATKCO in 
/?', and so T is not in crcatcd(s'). 

Fix U € siblings(T) D crcatcd(s'). Then there is a CREATE(U) in 0*. But then U is visible to 
T" in a\ so that a COMMIT for U occurs in a, and hence (because parcnt(U) is visible to T" in 
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a) a COM M IT for U occurs in fi\ Therefore, U € rcturncd(s'). 
(4.b) Immediate from lemma 10. 

(4.c) The first equality follows from Lemma 10. Clearly, /T = visiblc(/?\T") is a prefix of 
visible^ 'fi v '\'"). (equality follows because any operation in /J, visible to I" in /?*/?. would also be 
visible to T" in a\ and so would be in /?' and not/3.. I 

Corollary 69: Every weak concurrent schedule is serially correct for every non-orphan non- 
access transaction. 

Proof: let a be a weak concurrent schedule. Let T be a non-access transaction that is not an 
orphan in a. We must show that ofl' is a serial schedule. Note that T is not an orphan in any 
prefix of a. 

ITicrc arc three cases: 

(l)er|T is empty. 
Then the result is trivial. 

(2)T is live in a. 
Then Theorem 68 yields a serial schedule that is equivalent to visiblc(a,T). Thus, o|T = 
visiblc(o,T)|T = /J|T, which suffices. 

(3) T is a transaction which is live in some proper prefix of a. 
Since a is well-formed, a has a prefix a it, where w is a COMMIT operation for T, a'|T = a|T 
and T is live in a. Then Theorem 68 yields a serial schedule fi that is equivalent to 
visibIc(a\T)|T. Thus, a|T = a\Y = visiblc(a',T)|T = fi\\\ which suffices. I 

Now. since T fl cannot become an orphan (having no ancestors to abort), our first major correctness result is 
immediate. 

Corollary 70: Every weak concurrent schedule is serially correct for T fl . 

Having proved correctness properties for weak concurrent schedules, we arc now ready to prove the 
correctness of concurrent schedules. 

Ivcmma 71: Every concurrent execution is a weak concurrent execution. 

Proof: The proof is by induction on execution length, with a trivial basis. Let a = a\s\ir,s be a 
concurrent execution with (s>,s) a single step of the concurrent system, and assume the lemma 
holds for a\ Let s' c and s c denote the states of the concurrent controller in system states s' and s. 
If it is any operation other than an ABORT, the result is immediate, since the pre- and 
postconditions for all other operations arc identical in the concurrent and weak concurrent 
systems. Assume that w is an ABOR'I(T). We must show that T € crcatc-requcstcd(s' ) - 
rcturncd(s' ). c 

Since ir is enabled in state s' c in the concurrent controller, T € (crcatc-rcqucstcd(s' ) - 
crcatcd(s' c )) U (commit-rcqucstcd^) - rcturncd(s' c )). If T is in crcatc-rcqucstcd(s' C ) - 
crcatcd(s' c ). Lemma 45 implies that a contains no CRKATKfl} or ABORT(T) operation. ° By 
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well-formedness, a' also contains no COMMIT operation for T, and the result follows from 
Lemma 45. On the other hand, if'l' is in commit-rcqucslcd(s' c ) - rcturncd(s' c ). Lemma 45 implies 
that a RHQUHST-COMMIT operation for T occurs in a'. By well-formedness, this is preceded 
by a CRLATTX'T) operation, and by the concurrent controller precondition, this is preceded by a 
RLQULST-CRLA TL : fori'. Finally, again by Lemma 45, the result follows. I 

Now we can prove the second major result of the paper. 

Corollary 72: Hvcry concurrent schedule is serially correct. 

Proof: Let a be a concurrent schedule. Then a is also a weak concurrent schedule, by Lemma 
71, and is well-formed, by Lemma 61. We must show that o is serially correct for every 
transaction T. There arc three cases: 

(l)a|T is empty. 
Then the result is trivial. 

(2)T is live in a. 
By Lemma 50, all of Ts ancestors arc live in a, so that T is not an orphan in a. Then Corollary 69 
yields the result 

(3)T is a transaction which is live in some proper prefix of a. 
Uy Lemma 51, a has a prefix a'w, where w is a return operation for'T. a'|T = a |T and T is live in 
o'. By Lemma 50, all of Ts ancestors arc live in a\ so T is is not an orphan in a. Then Corollary 
69 implies that a is serially correct for T, so that a is serially correct for T. I 

For completeness, we include an analog of Theorem 68 for concurrent schedules. 

Theorem 73: Let a be a concurrent schedule, and T any transaction which is live in o. Then 
there is a serial schedule fi which is equivalent to visiblc(a,T). 

Proof: Lemma 71 implies that a is a weak concurrent schedule. Since T is live in a. Lemma 50 
implies that T is not an orphan in a. Then Theorem 68 yields the result I 

8. Discussion 

In this paper, we have presented a formal model for describing nested transaction systems and their 
properties. The model has many features that we believe make it a major contribution to the understanding 
of transaction systems, and we highlight some of these below. 

First the entire model is based on a very general and very simple underlying model for concurrent 
computation, the I/O automaton model. The general definitions and properties of this underlying model 
provide the necessary underpinnings for our entire transaction modelling effort This modelling is very easy 
to learn and use, and its usefulness extends much beyond transaction systems. Thus, it seems to us to be a 
very satisfactory foundation for our work. 

Our transaction system model permits simple, yet completely rigorous description of concurrency control 
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algorithms in ways which correspond very closely to the usual informal ways of understanding the algorithms. 
The important components of transaction systems, the transactions, data and schedulers, arc described 
explicitly, which greatly facilitates reasoning about them. 

There is a substantial amount of work in this area which docs not represent all of these components 
explicitly, but only implicitly, by properties of their behavior [Ly,IMG,Go, for example]. lricrc arc problems 
with this approach. A key ingredient that is usually absent from such implicit models is a clear notion of 
"causality", describing how particular actions (operations) arc triggered by other actions or states. In contrast, 
our explicit representation of all system components as I/O automata makes it easy to understand exactly 
what causes all operations to occur. When causality is important in reasoning about algorithms, as in [Go], 
implicit models can be extraordinarily difficult to use. Kvcn in cases where implicit models can be used, wc 
sec the present work as providing a formal and intuitive basis for that work. 

Our model represents transactions as essentially arbitrary automata, subject only to simple syntactic 
constraints. This approach is much more general than representing them as programs in some particular, 
overly-constrained language. 

The I/O automata model permits description of algorithms in an abstract form which is not tied to a 
particular programming language or system, and which allows maximum nondctcrminism. An 
implementation of an algorithm for a particular system will generally restrict the nondctcrminism allowed in 
our presentation, because of the need to tailor the implementation to the requirements of a particular 
environment. However, since the implementation is just a restriction of the abstract algorithm, correctness 
properties of the algorithm within our model will hold a fortiori for the implementation. 

Formulating nested transaction systems as I/O automata permits precise formulation of the correctness 
conditions to be satisfied by concurrency control algorithms; those correctness conditions can be stated at the 
transaction interface, an interface which docs not contain explicit information about object representation. 
Because of this choice of interface, the correctness conditions can be stated in a robust way: the same 
conditions can be useful for describing the properties of many different kinds of algorithms, some of which 
manipulate the data in very different ways. Also, the correctness conditions can be described in a way that is 
meaningful to a user of the system. 

The particular correctness conditions that we describe in this paper involve serial correctness at transaction 
interfaces. Wc believe that these particular correctness definitions are very interesting, and will be useful for 
describing the correctness of most of the usual algorithms studied in the concurrency control area. That is, the 
same conditions appear to be the right ones to use to describe correctness of many different kinds of 
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algorithms, including those that use locking, timcsuimps. multiple versions, and replicated data. 

Ihc model permits rigorous correctness proofs to be carried out for concurrency control algorithms in ways 
that follow intuitive understanding of the algoriUims. For example, in this paper, we have used the model to 
describe and show the correctness of a very important nested transaction concurrency control algorithm. Our 
correctness proofs arc constructive and provide considerable intuition about the workings of the algorithm. 
In contrast to most correctness proofs for concurrent algorithms, our prcxifs arc not voluminous low-level 
case-analyses; rather, they consist of a large number of clear and natural lemmas about the behavior of the 
algorithm. These lemmas can be understood individually, and build upon each other in the manner of good 
mathematics. Many of the lemmas should be reusable in extensions of this work as well. 

A successful model of nested transactions should contain the classical theory as a special case, in a way 
which is natural and sheds some light on that case. Wc believe that our model has contributed much to the 
classical theory. For example, the I/O automaton model provides a general underlying model, a missing 
component of the classical theory. Also, our explicit and general modelling of the transactions unifies the 
earlier collection of somewhat arbitrary approaches. Our use of the transaction interface for stating 
correctness conditions is also an improvement. 

Another contribution to the classical theory is in motivating scrializability as a correctness condition. 
Scrializability consists of two criteria: individually, each transaction must see a consistent state, and together, 
they must appear to run in a serial order. (A schedule in which each transaction reads and writes the initial 
state of the database provides a consistent state to each transaction, but is not scrializable.) Why is this second 
ordering property a part of the generally accepted correctness condition of the classical theory? Clearly, 
because of implicit nesting in the context of the transaction system. In practice, transactions perform tasks on 
behalf of some external entity or entities, which may expect one transaction to see the results of the next. In 
the natural formulation of classical systems within the present model, the classical transactions arc children of 
I' , with data accesses as their only children. Ihc root is an explicit representation of the external 
environment in which the system runs. Thus, the ordering property of scrializability is a natural consequence 
of the requirement that all transactions see serial schedules, including T Q . It docs not have to be introduced as 
an independent requirement in need of separate justification. 

By now, there has been a large amount of systems design and algorithms work that uses or implements 
nested transactions. It seems likely that these ideas will form the basis of future programming languages for 
distributed computing. However, there is currently a problem with the presentation of this work. Some of 
these algorithms arc presented in the context of specific systems and programming languages. Very useful 
and general ideas arc too intimately connected with details of the systems to be fully appreciated, particularly 
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for readers with only a passing understanding of those systems. ITiis level of detail also makes careful 
reasoning about the algorithms very difficult. 

Wc believe that our model has provided the necessary framework and some of the necessary vocabulary, for 
describing this work in a clear and unambiguous way. Wc arc currently studying much of this work on 
systems design and algorithms using our model, and our preliminary results indicate that it works very well. 

'throughout the paper, wc have described connections with other people's work as appropriate. Here, wc 
mention some of the particular modelling work that relates most closely to ours, and describe the connections 
in more detail. 

First, the pioneering work of Bernstein and Goodman [BG, etc.] has had a strong influence on this work. 
Quite early, they recognized the need for a model for single-level transaction systems, that would have many 
of the characteristics which wc have sought for nested transaction systems. They have carried out extensive 
research on precise understanding of single-level transaction concurrency control algorithms. They have 
presented formal statements of correctness conditions, in terms of scrializability of the accesses to data objects 
by different transactions. They have described some concurrency control algorithms with precision, and have 
proved correctness of some algorithms, using a lemma which characterizes scrializability by absence of cycles 
in a certain dependency relation. Their work has gone a long way toward providing precise understanding of 
the work in this area. 

However, the particular models used by Bernstein and Goodman have some problems which limit their 
applicability. For instance, the basic correctness condition is stated in terms of the interface between the data 
objects and the algorithm. There arc many algorithms which handle objects in very different ways, e.g. using 
multiple versions, or making multiple copies in order to permit "backing out" of operations. Since these 
algorithms do not preserve the specified object interface, they would not be considered correct under the 
same correctness condition. Thus, the correctness condition must be modified. Another limitation is that the 
proof technique, which involves proving absence of cycles, is a proof by contradiction; it does not give much 
insight into the operation of the algorithms. For many reasons, it is not at all clear how to extend these 
frameworks to handle nesting of transactions. 

Earlier attempts in [Ly,Go,BBGLS] to model nested transactions have made significant contributions. For 
example, [Ly] contains a language-independent model, which is used to give precise correctness conditions 
and a proof for a locking algorithm. Many of the ideas in that work have been useful in providing a 
vocabulary for talking about nested transactions. However, attempts to extend the model of [Ly] to handle 
correctness of orphans [Go] demonstrate that it is not sufficiently expressive. Certain aspects of the model 
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lead to icchnical difficulties; for example, it fails to model the transactions explicitly, using instead a 
specification of their behavior. Our new model builds on the strengths of the earlier work, while managing 
(we believe) to avoid its weaknesses. 

Finally, the very recent work in [IMG] proposes another general model for nested transactions. While on 
the surface the models appear quite different, they arc actually "compatible", in that the concepts described in 
[BUG] seem to be easily definable within our model. The style of the model in [BBG] is different from ours: 
their work models transactions and the scheduler implicitly, for instance. However, wc believe that their 
important axiomatic statements of properties can be described as assumptions and lemmas about behaviors of 
components in our model. Also, the partial orders which they use to model executions can actually be 
defined simply and directly in terms of our linearly-ordered executions. There arc many points of agreement: 
the use of the transaction interface for stating correctness conditions, and the use of the virtual root 
transaction T Q , to mention two. 

On the other hand, the emphasis in [BUG] is on a different example than the one studied in this paper. 
They consider multiple levels of abstraction for the data, and regard transactions at any level of the 
transaction tree as accesses to data at a corresponding level of abstraction. litis view meshes quite well with 
our model, where, for example, we use the same CREATE notation for creation of a transaction and 
invocation of an operation on data. Their paper clarifies the concurrency control requirements for data at 
different levels, when the correctness condition is serial correctness at T Q . We hope and expect that it will be 
easy to restate their results as claims about our model. 

Wc note that the work in [BBG] only treats concurrency control, but docs not address the very critical and 
difficult issues of resiliency. 

9. Further Work 

This paper is an embarkation on a major project to formulate a unified presentation of the most important 
algorithms for concurrency control and resiliency, especially those for nested transactions. So far, we have 
defined a general framework meeting the requirements outlined above. We have demonstrated the power of 
this framework by using it to specify two correctness conditions for nested transactions, to present two locking 
algorithms for implementing nested transactions, and to prove that the algorithms satisfy their respective 
requirements. 

Future extensions to this work will include treatment of many other algorithms in the same framework. 
Among the algorithms wc will consider arc timestamp and multivcrsion algorithms, algorithms which take 
advantage of special properties of the transactions and objects (semantic information), algorithms for orphan 
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management, and algorithms which use replicated data objects. Although our focus so far has been on nested 
transactions, we believe that our viewpoint contributes new insight to the special case of single-level 
transactions as well; thus, we will examine algorithms for non-nested transactions as well as nested 
transactions. 

We arc particularly interested in studying algorithms which give rise to live orphans, i.e. live transactions 
whose ancestors have aborted [Go,I.i,Wa,HM]. Our serial correctness condition provides a formal definition 
of orphan correctness - that all transactions (including orphans) "sec consistent data" [Go]. In fact, in work 
currently in progress [HLMW], we arc describing and proving correctness of several of the recently-developed 
algorithms for orphan management. This work now seems to be quite easy, given the foundation provided by 
the present paper. In fact, some of the key results of this paper arc used as lemmas in that work. 

Another direction of interest is the explicit representation of distribution within the model. It is fairly 
natural to model each transaction and object as located at different sites, each with a local automaton 
representing the resident portion of the (distributed) scheduler. These automata would communicate with 
each other in order to implement the (centralized) scheduler studied here, llic natural next step would be to 
model failure resilience, as various components lose information or fail altogether. 

The reader might have noted that our correctness conditions do not guarantee anything about the system 
making progress, but only about "safety" properties. Further work is needed to incorporate guarantees of 
progress. This work is likely to be difficult, however. Only recently, in [LT], have we achieved what we 
consider to be a satisfactory understanding of the eventuality and fairness issues for the basic I/O automaton 
model, so that wc can even formulate the conditions we want to satisfy. But even with the ability to state such 
conditions, the algorithmic issues still seem difficult. 
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